Messages in this thread | | | Subject | Re: [PATCH 05/15] drivers/char: minor irq handler cleanups | From | Benjamin Herrenschmidt <> | Date | Tue, 22 Apr 2008 18:05:40 +1000 |
| |
On Sat, 2008-04-19 at 08:00 +0200, Rogier Wolff wrote: > > You added a "XXX Using free_irq in the interrupt is not wise!". When I > wrote that code, I didn't know about this. These lines triggered when > the level-triggered PCI interrupt stuck "active" this would mean that > NO userspace code would get executed anymore: Hard lock up. Difficult > to debug. This happend a few times during development when the code > behind the "if (!polled)": "tell the hardware we've seen the > interrupt" didn't work. On the other hand, some failures in the field > have triggered this. So I think it's wise to keep it in. Disabling the > interrupt on the card is not an option, because that's exactly what > this is supposed to catch: We're unable to make the card stop > interrupting the CPU. > > Note that it also doesn't work (i.e. hard lock of the machine) if some > other driver is using the same interupt.
You should let the kernel generic code deal with the runaway interrupt, it should be capable of doing so nowadays pretty reliably.
free_irq() is definitely not going to be happy when it start messing with /proc from an interrupt... It will at least give you a WARN_ON.
Ben.
| |