Yes. What I'm talking about is lost interrupts _during processing of the
same interrupt_.
> IFF you only suffer from colaescing of interrupts the driver is perfect, it
> will loop processing events until the card says 'Im happy'.
Yes, that's what I meant, sorry. I should have made myself more clear.
Right now we do lose interrupts completely when somebody uses
"disable_irq() + enable_irq()", and that's because the code to "revive"
the interrupt is currently ifdeffed out.
> The NE2000 is quite happy in this situation providing your code has
> no races between the card interrupt line, the APIC and the interrupt
> enabling/irq return code. You _must_ guarantee that any irq from the instant
> we clear the flag on the PIC and 8390 controller will cause another irq to be
> issued, even if we are still in the IRQ handler return path as it occurs.
Yes, this atomicity is guaranteed by the irq_controller_lock, which
serializes the locking.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu