> On level triggered interrupts (which you need to support shared
> interrupts), wouldn't this create an interrupt loop?
>
> (i.e. a new interrupt occurs before the driver has had a chance to
> tell the hardware "yes, I'm looking into your problem".)
yes this could happen but this is why we enter drivers with interrupts
disabled. (unless the driver says otherwise)
> If I remember correctly, the symptoms are "hard lockup", most likely
> the keyboard hotkeys won't work any more.
i've never seen this, although many lockups were fixed. Particularly the
keyboard IRQ is usually an ISA one, edge triggered.
but this does show one possible major conceptual weakness of the
'decoupled IO-APIC' model. We 'early-ACK' the IO-APIC, which in turn opens
up a window for spurious interrupts. The right solution would be to
virtualize the 'device-ack' function, and to delay the APIC-ACK _to after_
the device itself has quit leveling the IRQ.
i have always kept an eye on this issue, but so far there was no single
report of 'spurious IRQs', although i think many drivers complain when it
happens. It might be that some PCI chipset feature takes care of this
issue. Maybe we were just lucky, there is a guaranteed timeout before yet
another IRQ is accepted, and the device-ACK usually happens right after
entering the IRQ handler.
i think i have mentioned this a few months ago, and got no comments ;)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu