On 28/03/14 20:38, Sergei Shtylyov wrote:
Hello.
On 03/28/2014 07:46 PM, Ben Dooks wrote:
The current behaviour of the sh_eth driver is not to use the RNC bit
for the receive ring. This means that every packet recieved is not only
generating an IRQ but it also stops the receive ring DMA as well until
the driver re-enables it after unloading the packet.
This means that a number of the following errors are generated due to
the receive packet FIFO overflowing due to nowhere to put packets:
net eth0: Receive FIFO Overflow
Setting the RMCR_RNC configuration has so far been tested with an NFS
root filesystem and the driver has not failed yet. It is not yet known
why this is not set for R8A779x operation
The reason is simple: it's not set on almost all 100 Mbs devices
except SH7757 (and most recently added R7S72100), so this was a matter
of copy-paste. I've had setting this bit on at least R-Car devices on my
aganda for some time but couldn't get to it yet.
(Feedback on this issue or other testing is welcome)
OK, I'll try it with netperf UDP test known to generate handful of
the aforementioned errors, when I have time.
I find the best way is to either use NFS-root or turn on all the
locking debugging, it seems to slow things down enough for the
RX FIFO to overflow.
From a quick debug, I saw that each RX IRQ delivered one packet
from the ring buffer before requiring the hardware received to
be re-started.
So far I have not had any chance to make any speed tests, however
it has cleared off a lot of the fifo messages off my nfs-root tests
here. I've had a ring-error, but that was due to another driver
holding interrupts for far too long.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html