| Message ID | 1396025185-7911-1-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
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.
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. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > > WBR, Sergei Has anyone had time to look at this?
Hi Ben, On Mon, Apr 14, 2014 at 2:47 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > On 28/03/14 20:38, Sergei Shtylyov wrote: >> 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. > > Has anyone had time to look at this? I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't see any good or ill effects. Just using NFS root and generating some I/O, so nothing fancy. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 14, 2014 at 6:35 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Mon, Apr 14, 2014 at 2:47 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: >> On 28/03/14 20:38, Sergei Shtylyov wrote: >>> 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. >> >> Has anyone had time to look at this? > > I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't > see any good or ill effects. Just using NFS root and generating some I/O, > so nothing fancy. FWIW, I still have "renesas,no-ether-link" in the ethernet node in DT. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 04/14/2014 08:48 PM, Geert Uytterhoeven 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. >>> Has anyone had time to look at this? >> I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't >> see any good or ill effects. Just using NFS root and generating some I/O, >> so nothing fancy. > FWIW, I still have "renesas,no-ether-link" in the ethernet node in DT. You shouldn't need it anymore if you're using recent devel branch of the renesas.git repo: it already has the necessary PHY driver and device tree changes to avoid the issue which specifying that prop fixed. > Gr{oetje,eeting}s, WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 04/14/2014 04:47 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. >> WBR, Sergei > Has anyone had time to look at this? OK, I've finally tried netperf and couldn't get it to reproduce these errors on any R-Car gen2 board. I was only able to reproduce this error on a new R8A7791 board during NFS boot, and applying the patch seems to have helped. So you can add my: Tested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c index 942f1a9..7b02b70 100644 --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -467,6 +467,7 @@ static struct sh_eth_cpu_data r8a779x_data = { .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD, .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP, .eesipr_value = 0x01ff009f, + .rmcr_value = RMCR_RNC, .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO, .eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
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 (Feedback on this issue or other testing is welcome) Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> --- drivers/net/ethernet/renesas/sh_eth.c | 1 + 1 file changed, 1 insertion(+)