Messages in this thread | | | Date | Mon, 8 Nov 1999 01:38:31 +0100 (MET) | From | Gerard Roudier <> | Subject | RE: Common IRQ pitfall results in lockup. |
| |
On Fri, 5 Nov 1999, Bret Indrelee wrote:
> That is how almost every other operating system that uses polled interrupts > does it. The handler returns one defined value if they didn't handle it and > a different value if it was handled. > > I was surprised that Linux didn't have the driver poll routine return a > value.
I am not surprised at all when thinking about level-sensitive interrupts as PCI.
Reading the PCI BUS from the CPU is way-stupid since such a transaction is not posted. We must avoid that each time it is possible.
A well-designed PCI-device should allow not to do so. Basically, the CPU would just have clear some flag that is known to cause the interrupt without having read it at all and then scan some done queue in memory.
Note that if the write is not flushed quickly enough, the interrupt will be raised again. :)
Anyway, the chip can do (if possible): - Clear the flag without reading it - Perform a dummy read to flush the previous write if posted - Scan some done queue.
This spare a read from the PCI BUS and the C code is still not able to tell you if it has really cleared something. :)
Between you and me, a driver that missed to clear the interrupt condition is pretty unlikely to exist. May-be I am too optimitic ? Am I so ? :)
In my opinion, if you base you interrupt polling on some return value with PCI, you run the risk to be confused by some cause-to-effect assumption that does not apply to PCI and just do wrong things.
Basically you must call each interrupt routine once and only once for an IRQ that is shared and if such a simple thing does not work, then better to throw away computers and to learn to count on fingers. ;-)
Gérard.
- 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/
| |