Messages in this thread | | | Date | Fri, 5 Nov 1999 22:25:42 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Common IRQ pitfall results in lockup. |
| |
From: "Raj, Ashok" <ashok.raj@intel.com> Date: Fri, 5 Nov 1999 08:29:48 -0800
Another one i would recommend if this is making its way to the base linux kernel is that we should ask the irq handlers to return some value so that the kernel could know who took this interrupt. so if 2 devices are sharing an interrupt, and if the kernel calls the first registered handler, and it knew its device interrupted, then on returning from the irq handler if we return 1 to indicate this interrupt is consumer, we possibly dont need to send this to all of the registered handlers?
Life gets a bit more tricy on the ISA bus, because interrupts are edge triggered. Suppose while you're servicing device #1, device #2 signals an interrupt. If you don't check device #2 before you exit, the IRQ is still high, and since interrupts are edge triggered, that IRQ channel won't cause any more interrupts, and device #1 and #2 will *both* be dead in the watter.
So yes, having the irq handlers return a signal indicating whether they serviced the device is useful, but if you're going to share interrupts that are edge triggered, what you have to do is repeatedly call *all* of them over and over again until they all report that all of the devices don't need servicing, and hope/pray you don't hit a race condition where a device became ready while you were checking the other devices in the chain. (This is why I don't recommend using more than 16 serial ports on a single IRQ, at least when using an ISA bus. The serial driver has watchdog timers to recover if the interrupt line gets wedged, but characters will likely still get lost unless the UART's have very deep FIFO's.)
That's in fact how the serial driver supports multiple serial ports sharing a single IRQ, at least on an ISA bus. On a saner bus architecture, where interrupts are level-triggered, this is much less of an issue --- although there's a tradeoff; if a device driver is buggy and doesn't know how to make its interrupt service routine clear whatever condition is causing the device to assert an interrupt, the system will lock up.
So yes, having the irq handlers return an indication of whether they serviced the device is useful, but *how* that indication gets used may have to change depending the bus architecture.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |