Hello,

> But NetBSD calls gc_enable_irq() _before_ calling the pending interrupt handlers.
Yes, when processing pending interrupts it takes one, enables the corresponding IRQ and then calls the handler(s).

> For unintelligent interrupt controllers, this is correct for edge-sensitive and
> unshared level-sensitive interrupts.  A race condition exists for shared level-
> sensitive interrupts: when two devices have pending interrupts, the interrupt line
> is never deasserted if the first device gets another interrupt before the second
> device is handled.
Hmm, I'm not sure I got this right - the current code calls all handlers associated with an IRQ before proceeding. If another one comes in it gets deferred, marked as pending and the IRQ gets disabled again, so in the next loop it will see the interrupt again and should get through to the 2nd device eventually - as far as I can tell it always calls all handlers for a given IRQ.

have fun
Michael