Re: [elysium-developers] IRQ handling

[Kasper V. L. <ve...@da...>]

> > Is it a problem that a handler for an IRQ never can be interrupted by
> > another request for the same IRQ?
>
> I don't think so. The IRQ will be dropped if that come too fast
> wont they? That must happen in all kernels so someone else must
> have solved the problem, if there is a problem to solve. I think
> we might have a problem with somethings like net cards:
>
> * Packet arrives
> * IRQ 9 handler called
> * Packet arrives
> * IRQ 9 handler ends
>
> Now I think the second IRQ would be dropped by the PIC, not qued.
> so the second packet wouldn't be handled. But cards might have a
> way around this (e.g. a register to poll, at the end of the handler.)

There is some level of buffering in the PIC - in the sense that while an
interrupt is being serviced the appropriate bit in the ISR will remain high
(until we send a specific EOI), but AFAIK the bits in the IRR (which is the
8-bit register the devices sets bits in by pulling some IRQ line) are free
to be 1. So in your example it would actually be something like:

* packet arrives (bit set in ISR)
* IRQ 9 handler called
* packet arrives (bit set in IRR, and in ISR)
* IRQ 9 handler ends
* IRQ 9 handler called (because the bit in the IRR is transferred to ISR on
EOI)
* IRQ 9 handler ends

Of course this doesn't work for any number of packet arrivals since the
level of buffering is static (1 buffer register). Does anyone know anything
about how it's handled by the Linux kernel?

/Kasper