Messages in this thread | | | Date | Thu, 20 May 2010 07:39:27 -0700 | From | Darren Hart <> | Subject | Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY) |
| |
On 05/20/2010 01:14 AM, Thomas Gleixner wrote: > On Thu, 20 May 2010, Jan-Bernd Themann wrote: >>>> Thought more about that. The case at hand (ehea) is nasty: >>>> >>>> The driver does _NOT_ disable the rx interrupt in the card in the rx >>>> interrupt handler - for whatever reason. >>> >>> Yeah I saw that, but I don't know why it's written that way. Perhaps >>> Jan-Bernd or Doug will chime in and enlighten us? :) >> >> From our perspective there is no need to disable interrupts for the >> RX side as the chip does not fire further interrupts until we tell >> the chip to do so for a particular queue. We have multiple receive > > The traces tell a different story though: > > ehea_recv_irq_handler() > napi_reschedule() > eoi() > ehea_poll() > ... > ehea_recv_irq_handler()<---------------- ??? > napi_reschedule() > ... > napi_complete() > > Can't tell whether you can see the same behaviour in mainline, but I > don't see a reason why not.
I was going to suggest that because these are threaded handlers, perhaps they are rescheduled on a different CPU and then receive the interrupt for the other CPU/queue that Jan was mentioning.
But, the handlers are affined if I remember correctly, and we aren't running with multiple receive queues. So, we're back to the same question, why are we seeing another irq. It comes in before napi_complete() and therefor before the ehea_reset*() block of calls which do the equivalent of re-enabling interrupts.
-- Darren
> >> queues with an own interrupt each so that the interrupts can arrive >> on multiple CPUs in parallel. Interrupts are enabled again when we >> leave the NAPI Poll function for the corresponding receive queue. > > I can't see a piece of code which does that, but that's probably just > lack of detailed hardware knowledge on my side. > > Thanks, > > tglx
-- Darren Hart IBM Linux Technology Center Real-Time Linux Team
| |