[parisc-linux-cvs] linux-2.6 willy
James Bottomley
James.Bottomley at SteelEye.com
Mon Jan 3 09:35:19 MST 2005
On Sun, 2005-01-02 at 22:30 -0700, Grant Grundler wrote:
> On Sun, Jan 02, 2005 at 04:53:10PM -0600, James Bottomley wrote:
> > 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.
I didn't say we don't call all handlers for an irq. What I do assert is
that on our first unhandled interrupt, the line remains asserted and now
all interrupts from the other cards are lost because we have no choice
but to shut the line down to allow the machine to make forward progress.
Perhaps I should clarify what disable_irq() is actually for: you only
call it from your interrupt routine when you know you're taking a course
of action which will lead to the interrupt you were trying to handle
being still asserted. There's no case (except a driver bug) where we
should be calling disable_irq() speculatively without the line asserted.
So if we didn't shut the line down, it would loop with an unhandled
interrupt and get shut down anyway. That's why (2) is marginally better
than (1).
James
More information about the parisc-linux-cvs
mailing list