Hello,

> If an interrupt comes in after enabling it (gc_enable_irq) but before
> ci->ci_ipending is unset, would you lose the interrupt? 
Depends - if processor interrupts are enabled it will be processed normally, if not gc_read_irq() will see it.

> Seems to me that Neil's post indicates that simply blinding turning off the
> pending virq without making sure the hardware irq has been deasserted with
> gc is leaving room to miss some stuff.
No need to do that as long as it's marked as pending. 
When do_pending_intr() kicks in it will re-enable the interrupt and my patch will make sure it gets cleared.

> The code overall attempts to turn off the pending interrupt, call the
> handlers, and then see if they all deasserted the interrupt. If the
> interrupt is still asserted, kick it back into the loop. I could be wrong,
> but in the process of iterating over the handlers, a device whose handler
> has already been called for this interrupt cycle could request another
> interrupt, but it does not get noted because the interrupt was never
> deasserted. To me it seems abiguous as to whether a fresh call to ext_intr
> would be generated if the interrupt remained asserted.
Good question, but I doubt gc will fire a new interrupt if the line doesn't get deasserted in between.

I still think there should be a counter to prevent an infinite loop ( and therefore a hang ) if an IRQ doesn't get deasserted for whatever reason. We should probably limit it to 10 loops or so and then exit - if the IRQ is still asserted when the next timer IRQ fires we'll go through the same thing again but we won't lock up.

have fun
Michael