Re: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)

From: Darren Hart
Date: Thu May 20 2010 - 10:39:44 EST

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()<---------------- ???

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.


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.



Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at