The combination of r35942 and r35952 causes an issue where eth_schedule_poll()
can be called from a different CPU between the call to napi_complete() and the
setting of cur_index which can break the rx ring accounting and cause ethernet
latency and/or ethernet stalls. The issue can be easilly created by adding
a couple of artificial delays such as:
@@ -715,6 +715,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
if (!received) {
napi_complete(napi);
+udelay(1000);
enable_irq(IRQ_CNS3XXX_SW_R0RXC);
}
@@ -727,6 +728,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
rx_ring->cur_index = i;
wmb();
+udelay(1000);
enable_rx_dma(sw);
return received;
This patch moves the setting of cur_index back up where it needs to be and
addresses the original corner case that r35942 was trying to catch in an
improved fashion by checking to see if the rx descriptor ring has become
full before interrupts were re-enabled so that a poll can be scheduled again
and avoid an rx stall caused by rx interrupts ceasing to fire again.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
SVN-Revision: 39761
When an rx interrupt comes in, rx interrupts are disabled and NAPI
polling is scheduled. During the NAPI poll, the driver first processes
received frames in the ring, then fills the dma descriptor slots with
new buffers and calls tx complete, before finally re-enabling rx
interrupts and completing NAPI (if below the budget).
If the hardware rx queue overflows before the napi complete is called,
the hardware will not throw any further rx interrupts and rx processing
stops completely.
Fix this by keeping NAPI polling scheduled until it completes a poll
without receiving any packets, and also handle NAPI completion before
refilling rx or completing tx.
SVN-Revision: 35942
