On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote:
> * Stefan Sørensen <stefan.sorensen@xxxxxxxxxxxxxxx> [140224 02:12]:
> > Currently INTC interrupts are handled using handle_level_irq which
> > will acknowledge the interrupt before running the handler. If a second
> > interrupt is then asserted and this interrupt is disabled while
> > running the first handler, the INTC will be brought into an
> > inconsistent state.
>
> Hmm care to explain a bit more here if the second interrupt you're
> talking about is the same interrupt or any interrupt in the same
> interrupt bank? Is this limited to GPIO interrupts?
I am seeing it with the cpsw driver on a custom board and on the
beaglebone. When a tx irq is handled the cpsw irq handler disables both
the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex
traffic), this bug will trigger. Reproducing it is very simple, just hit
a beaglebone with a flood ping and watch a function trace.
Applying this patch I see a significant performance boost on duplex
traffic. An iperf full duplex test gives a 50-100% increase in receive
bandwidth - it now fully saturates a 100Mb interface, so the increase
might be even larger with a gigabit interface.
> The reason I'm asking is because of the issues we've seen earlier
> with not flushing posted writes from the interrupt handlers. In
> those case the interrupt on the device gets acked too late without
> the read back call.
I am not very familiar with the low level details of the irq handling,
but am335x TRM states that a data synchronization barrier should be used
after the ACK is posted to the INTC, and I don't see that anywhere in
the code. Is this related?
Stefan
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
