Re: ASM1083 PCIx-PCI bridge interrupts - widespread problems

From: Clemens Ladisch
Date: Thu Feb 02 2012 - 16:40:09 EST

Edward Donovan wrote:
> * New logic in the generic IRQ code, in spurious.c, adding a "try
> polling, then re-enable for
> a while" method, for everybody?

This is useful in the general case, if the interrupt line eventually
gets unstuck. With the ASM1083, we know this happens when another
interrupt comes in, but we don't know when (the sound card mentioned in
the link above issues interrupts every few milliseconds; Jeroen's on-
board FireWire controller fires a timer every 64 s; his network card
might not get any action if there isn't any traffic).

> * A warning message about ASM1083, under arch/ or drivers/ ? A better
> place for special checks, than the genirq code. (Right?)


> * Could there be more hardware-specifc code, to crank up the
> frequency,

... and lower the threshold for detecting a stuck interrupt, ...

> when you do have this chip?

This would be sensible, as this is not a catch-all debugging measure but
a workaround for a known problem.

> I don't think we have this facility at present: would we let the
> arch-or-drivers code set a variable, to be honored by irq/spurious.c?

Wouldn't be the first one that affects generic code.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at