Re: [GIT PATCH] more Driver core patches for 2.6.19

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> 
> Rather than IRQ_HANDLED, it should have been: remove this irq handler 
> from the irq handlers for irq number N, so that it does not get called 
> again until userspace has acked it.

Wrongo.

That just means that the _handler_ won't be called.

But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS 
FOR THAT INTERRUPT will be called. 

Over and over again. Forever. Because the machine won't be making any 
progress, and the user-level code (which might know how to shut it up) 
won't ever be called, because the machine is busy just doing interrupt 
delivery all the time.

> See, maybe I don't have enough clue yet to exactly figure out why you 
> say it does not work. However, this is how simple people see it 8)

You may be a bit simple. But I think it's more polite to call you 
"special". Or maybe just not very used to how hardware works.

Btw, this is not something theoretical. We used to have this particular 
problem _all_ the time with PCMCIA back when we weren't as good at 
interrupt routing. You'd insert a PCMCIA card, and the machine just hung. 
Hard.

And the reason was that it would send an irq, but we were expecting it on 
another interrupt. But if it showed up on something that was shared, you'd 
have a hung machine, because you'd just have the (say) ethernet driver 
saying "not for me", and returning. And obviously not able to actually 
shut it up, so when we returned from the interrupt handler, the interrupt 
happened immediately again.

So this really isn't theoretical. It's a very common failure schenario for 
mishandled interrupts. In fact, exactly because it's so common, these days 
we have all this special logic in the generic interrupt layer that 
notices, and shuts them up entirely (but does so by disabling _all_ the 
devices on that interrupt, so when this happens, you might well lose your 
disk driver or somethign else).

			Linus