[parisc-linux-cvs] linux-2.6 willy

[Grant Grundler]

On Sun, Jan 02, 2005 at 04:53:10PM -0600, James Bottomley wrote:
> Consider the end result:  assume we have a PCI card with level triggered
> interrupts we can't shut down, but we need it to stop squeaking while we
> do packet processing or packet receive mitigation (this is, sadly, quite
> a common case).

Yes - I agree this is a very ugly case since it could imply one or more
spurious interrupts until the kernel decides to squash that interrupt
source on it's own. Not something we want to have happening on
a regular basis.

> In 1) we disable the routine while the card is processing, but since its
> interrupt line is asserted, it's already masking any other shared
> interrupt.  If we just allow this to go on, every time we enable
> interrupts, we get another one on this line.  Eventually the machine
> bogs (no forward progress) because it's simply re-interrupting every
> time we try to handle the line's interrupt but find no-one wants it.
> Thus, we're forced to shut the line up.  Even if the other cards are
> trying to interrupt, they're usually lost in the noise.

I don't agree with the last sentence - we *must* call all handlers
registered for a particular IRQ line (only level triggered IRQs
can be shared) when any one of the devices sharing the IRQ interrupts.
I.e. we will call the remaining handler(s) and if they all say
"not mine", then we can deduce this is a spurious interrupt.

If we don't squelch the IRQ after one (or more) spurious interrupts,
then we will get "live lock" where the EOI for the current interrupt
effectively triggers the next interrupt. We don't get many cycles
of work done between exiting the current interrupt context and entering
the next one. (IIRC, only "bottom-half" stuff and signals get delivered.)

> In 2), we disable the IRQ line proactively.  Now, we stop listening to
> all cards on the line (interference) but at least the kernel makes
> forward progress until the bad card is ready to re-enable the interrupt
> line.

My fear is the case where the driver for the "bad card" never
re-enables the IRQ line. e.g. shutdown a driver instance.

> > I consider (2) more evil because it always interfers with 
> > other devices even when the HW is not broken.
> > But I'm assuming (1) is "consistently diagnosed" and I'm not
> > real comfortable yet it's a valid assumption - it's a hard one to prove.
> 
> The general rule should be don't share interrupts, not at all, never,
> not even when the docs say its OK (and sadly a lot of ACPI and APIC
> programming rules force shared interrupts on us anyway).

Agreed - lots of reasons to not share IRQs.

> Then, if the line isn't shared, (2) is clearly better.

Well, "last" driver to disable the IRQ could be the same for
both shared/unshared cases IMHO.
(shared active -> one active handler -> disabled)

> For shared lines, I'd still argue that (2) is the lesser of the evils.

ok.  I'll defer presenting to this change to the broader
kernel community until I hear something more encouraging. 

thanks,
grant