On 04/24/2013 06:46 AM, Joerg Roedel wrote:
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
Given other threads on this mail list (and I've seen crashes with same problem)
where this type of logging during a flood of IOMMU errors will lock up the
machine,
is there something that
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
> Given other threads on this mail list (and I've seen crashes with same
> problem)
> where this type of logging during a flood of IOMMU errors will lock up the
> machine,
> is there something that can be done to break the do-while loop
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
Given other threads on this mail list (and I've seen crashes with same
problem)
where this type of logging during a flood of IOMMU errors will lock up the
machine,
is there something that can be done to break the do-while loop
On 04/24/2013 06:46 AM, Joerg Roedel wrote:
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
Given other threads on this mail list (and I've seen crashes with same problem)
where this type of logging during a flood of IOMMU errors will lock up the
machine,
is there something that
On 04/18/2013 12:28 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
This workaround is required for both event log and ppr log. Your
patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
From
On 04/18/2013 12:28 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
This workaround is required for both event log and ppr log. Your
patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
From
On 4/18/2013 3:06 PM, Joerg Roedel wrote:
Yes, but the irq-thread function itself executes the handler function
repeatedly until the IRQTF_RUNTHREAD bit is cleared. And every new
interrupt will set this bit again. So when there is a new interrupt
while our handler function runs the handler will
On 4/18/2013 3:06 PM, Joerg Roedel wrote:
Yes, but the irq-thread function itself executes the handler function
repeatedly until the IRQTF_RUNTHREAD bit is cleared. And every new
interrupt will set this bit again. So when there is a new interrupt
while our handler function runs the handler will
On Thu, Apr 18, 2013 at 01:56:42PM -0500, Suthikulpanit, Suravee wrote:
> On 4/18/2013 1:35 PM, Joerg Roedel wrote:
> According to the "kernel/irq/handle.c:irq_wake_thread()", I thought
> that for the threaded IRQ, if the system getting a new interrupt
> from the device while the thread is
On 4/18/2013 1:35 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:59:58AM -0500, Suthikulpanit, Suravee wrote:
One last concern I have for this patch is the case when we re-enable
the interrupt, then another interrupt happens while we processing
the log and set the bit. If the interrupt
On Thu, Apr 18, 2013 at 11:59:58AM -0500, Suthikulpanit, Suravee wrote:
> One last concern I have for this patch is the case when we re-enable
> the interrupt, then another interrupt happens while we processing
> the log and set the bit. If the interrupt thread doesn't check this
> right before
Joerg,
One last concern I have for this patch is the case when we re-enable the
interrupt, then another interrupt happens while we processing the log
and set the bit. If the interrupt thread doesn't check this right
before the thread exits the handler. We could still end up leaving the
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
> This workaround is required for both event log and ppr log. Your
> patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
>From cebe04596989c4b9001e2c1571c4fb219ea37b99 Mon Sep
Joerg,
This workaround is required for both event log and ppr log. Your patch
is only taking care of the event log.
Suravee
On 4/18/2013 11:02 AM, Joerg Roedel wrote:
On Mon, Apr 15, 2013 at 02:07:46AM -0500, suravee.suthikulpa...@amd.com wrote:
drivers/iommu/amd_iommu.c | 145
On Mon, Apr 15, 2013 at 02:07:46AM -0500, suravee.suthikulpa...@amd.com wrote:
> drivers/iommu/amd_iommu.c | 145
> +
That is way too much for a simple erratum workaround, and too much for a
stable backport. I queued the patch below instead, which has
On Mon, Apr 15, 2013 at 02:07:46AM -0500, suravee.suthikulpa...@amd.com wrote:
drivers/iommu/amd_iommu.c | 145
+
That is way too much for a simple erratum workaround, and too much for a
stable backport. I queued the patch below instead, which has a
Joerg,
This workaround is required for both event log and ppr log. Your patch
is only taking care of the event log.
Suravee
On 4/18/2013 11:02 AM, Joerg Roedel wrote:
On Mon, Apr 15, 2013 at 02:07:46AM -0500, suravee.suthikulpa...@amd.com wrote:
drivers/iommu/amd_iommu.c | 145
On Thu, Apr 18, 2013 at 11:13:19AM -0500, Suravee Suthikulanit wrote:
This workaround is required for both event log and ppr log. Your
patch is only taking care of the event log.
Right, thanks for the notice. Here is the updated patch.
From cebe04596989c4b9001e2c1571c4fb219ea37b99 Mon Sep 17
Joerg,
One last concern I have for this patch is the case when we re-enable the
interrupt, then another interrupt happens while we processing the log
and set the bit. If the interrupt thread doesn't check this right
before the thread exits the handler. We could still end up leaving the
On Thu, Apr 18, 2013 at 11:59:58AM -0500, Suthikulpanit, Suravee wrote:
One last concern I have for this patch is the case when we re-enable
the interrupt, then another interrupt happens while we processing
the log and set the bit. If the interrupt thread doesn't check this
right before the
On 4/18/2013 1:35 PM, Joerg Roedel wrote:
On Thu, Apr 18, 2013 at 11:59:58AM -0500, Suthikulpanit, Suravee wrote:
One last concern I have for this patch is the case when we re-enable
the interrupt, then another interrupt happens while we processing
the log and set the bit. If the interrupt
On Thu, Apr 18, 2013 at 01:56:42PM -0500, Suthikulpanit, Suravee wrote:
On 4/18/2013 1:35 PM, Joerg Roedel wrote:
According to the kernel/irq/handle.c:irq_wake_thread(), I thought
that for the threaded IRQ, if the system getting a new interrupt
from the device while the thread is running, it
From: Suravee Suthikulpanit
The IOMMU interrupt handling in bottom half must clear the PPR log interrupt
and event log interrupt bits to re-enable the interrupt. This is done by
writing 1 to the memory mapped register to clear the bit. Due to hardware bug,
if the driver tries to clear this bit
From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
The IOMMU interrupt handling in bottom half must clear the PPR log interrupt
and event log interrupt bits to re-enable the interrupt. This is done by
writing 1 to the memory mapped register to clear the bit. Due to hardware bug,
if the
24 matches
Mail list logo
