On Thu, 20 May 2010, Darren Hart wrote: > 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.
Can you slap a few trace points into that driver with a stock mainline kernel and verify that ? Thanks, tglx _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev