| Message ID | 20170707013257.18250-1-joseph.kogut@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Joseph, Joseph Kogut <joseph.kogut@gmail.com> writes: > Meson GXL appears to suffer from the same broken eee issue as GXB, > originally fixed by feb3cbea0946. > > This patch disables the broken energy-efficient ethernet for GXL, > avoiding the tx link breakage. > > Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> Can you share what platforms you tested to find/fix this problem? Thanks for the patch! Kevin
Hi Kevin, I tested on a P212 reference board, which is currently the only GXL based board I have. Before applying the patch, high activity on the ethernet interface would cause the link to break, requiring the interface to be brought down and back up before it would work again. After applying the patch, I could not get the link to break with any transfers.
On 07/23/2017 07:03 PM, Joseph Kogut wrote: > Hi Kevin, > > I tested on a P212 reference board, which is currently the only GXL > based board I have. > > Before applying the patch, high activity on the ethernet interface > would cause the link to break, requiring the interface to be brought > down and back up before it would work again. After applying the patch, > I could not get the link to break with any transfers. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > Hi Joseph, [please keep the history of the conversation when replying] Is it a original P212 board, or a board based on the P212 ref design ? I'm currently testing the v4.13-rc2 on the official P212 board we received from Amlogic and using iperf3 in both directions, I have an issue after a few minutes running iperf3 with : # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done That cycles between the two iperf directions. After a few minutes, it stalls with : Connecting to host 192.168.1.21, port 5201 [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes And then, after: # ifconfig eth0 down # ifconfig eth0 up It cycles between : [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down and so on. And this patch does not fix this at all. It seems to be more a PHY driver issue here. Could you share the results with the same command ? Neil
On 07/24/2017 02:06 PM, Neil Armstrong wrote: > On 07/23/2017 07:03 PM, Joseph Kogut wrote: >> Hi Kevin, >> >> I tested on a P212 reference board, which is currently the only GXL >> based board I have. >> >> Before applying the patch, high activity on the ethernet interface >> would cause the link to break, requiring the interface to be brought >> down and back up before it would work again. After applying the patch, >> I could not get the link to break with any transfers. >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > Hi Joseph, > > [please keep the history of the conversation when replying] > > Is it a original P212 board, or a board based on the P212 ref design ? > > I'm currently testing the v4.13-rc2 on the official P212 board we received from Amlogic > and using iperf3 in both directions, I have an issue after a few minutes running iperf3 with : > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done > > That cycles between the two iperf directions. > > After a few minutes, it stalls with : > > Connecting to host 192.168.1.21, port 5201 > [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 > [ ID] Interval Transfer Bandwidth Retr Cwnd > [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > And then, after: > # ifconfig eth0 down > # ifconfig eth0 up > > It cycles between : > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down > > and so on. > > And this patch does not fix this at all. > > It seems to be more a PHY driver issue here. > > Could you share the results with the same command ? > > Neil > I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled, only relying on the Generic PHY Driver. [ 630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) When the PHY driver is loaded the issue disappears, with and without your patch. [ 25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) Could you please check the PHY Driver is loaded ? Thanks, Neil
On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote: > On 07/24/2017 02:06 PM, Neil Armstrong wrote: > > On 07/23/2017 07:03 PM, Joseph Kogut wrote: > > > Hi Kevin, > > > > > > I tested on a P212 reference board, which is currently the only GXL > > > based board I have. > > > > > > Before applying the patch, high activity on the ethernet interface > > > would cause the link to break, requiring the interface to be brought > > > down and back up before it would work again. After applying the patch, > > > I could not get the link to break with any transfers. > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > > > > Hi Joseph, > > > > [please keep the history of the conversation when replying] > > > > Is it a original P212 board, or a board based on the P212 ref design ? > > > > I'm currently testing the v4.13-rc2 on the official P212 board we received > > from Amlogic > > and using iperf3 in both directions, I have an issue after a few minutes > > running iperf3 with : > > > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done > > > > That cycles between the two iperf directions. > > > > After a few minutes, it stalls with : > > > > Connecting to host 192.168.1.21, port 5201 > > [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 > > [ ID] Interval Transfer Bandwidth Retr Cwnd > > [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes > > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > Same kind of test shows no issue on the libretech-cc and the khadas-vim In this case, I don't think meson-gxl.dtsi is where you should make your change. > > > > And then, after: > > # ifconfig eth0 down > > # ifconfig eth0 up > > > > It cycles between : > > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - > > 100Mbps/Full - flow control rx/tx > > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down > > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - > > 100Mbps/Full - flow control rx/tx > > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down This does not look like the issue we had on the odroid-c2. However, I have seen behavior like this (link down/up flickering) when the rgmii delays are way off. Maybe you could try playing with "amlogic,tx-delay-ns" property ? > > > > and so on. > > > > And this patch does not fix this at all. > > > > It seems to be more a PHY driver issue here. > > > > Could you share the results with the same command ? > > > > Neil > > > > I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled, > only relying on the > Generic PHY Driver. > > [ 630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY] > (mii_bus:phy_addr=0.e40908ff:08, irq=-1) > > > When the PHY driver is loaded the issue disappears, with and without your > patch. > > [ 25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver > [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) > > Could you please check the PHY Driver is loaded ? > > Thanks, > Neil
On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote: >> On 07/24/2017 02:06 PM, Neil Armstrong wrote: >> > On 07/23/2017 07:03 PM, Joseph Kogut wrote: >> > > Hi Kevin, >> > > >> > > I tested on a P212 reference board, which is currently the only GXL >> > > based board I have. >> > > >> > > Before applying the patch, high activity on the ethernet interface >> > > would cause the link to break, requiring the interface to be brought >> > > down and back up before it would work again. After applying the patch, >> > > I could not get the link to break with any transfers. >> > > >> > > _______________________________________________ >> > > linux-arm-kernel mailing list >> > > linux-arm-kernel@lists.infradead.org >> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > >> > >> > Hi Joseph, >> > >> > [please keep the history of the conversation when replying] >> > >> > Is it a original P212 board, or a board based on the P212 ref design ? >> > >> > I'm currently testing the v4.13-rc2 on the official P212 board we received >> > from Amlogic >> > and using iperf3 in both directions, I have an issue after a few minutes >> > running iperf3 with : >> > >> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done >> > >> > That cycles between the two iperf directions. >> > >> > After a few minutes, it stalls with : >> > >> > Connecting to host 192.168.1.21, port 5201 >> > [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 >> > [ ID] Interval Transfer Bandwidth Retr Cwnd >> > [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes >> > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > Same kind of test shows no issue on the libretech-cc and the khadas-vim > In this case, I don't think meson-gxl.dtsi is where you should make your change. > >> > >> > And then, after: >> > # ifconfig eth0 down >> > # ifconfig eth0 up >> > >> > It cycles between : >> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - >> > 100Mbps/Full - flow control rx/tx >> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down >> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - >> > 100Mbps/Full - flow control rx/tx >> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down > > This does not look like the issue we had on the odroid-c2. > However, I have seen behavior like this (link down/up flickering) when the rgmii > delays are way off. > > Maybe you could try playing with "amlogic,tx-delay-ns" property ? we need to change dwmac-meson8b.c so it applies the TX delay also for RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs, see: [0] >> > >> > and so on. >> > >> > And this patch does not fix this at all. >> > >> > It seems to be more a PHY driver issue here. >> > >> > Could you share the results with the same command ? >> > >> > Neil >> > >> >> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled, >> only relying on the >> Generic PHY Driver. >> >> [ 630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY] >> (mii_bus:phy_addr=0.e40908ff:08, irq=-1) >> >> >> When the PHY driver is loaded the issue disappears, with and without your >> patch. >> >> [ 25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver >> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) >> >> Could you please check the PHY Driver is loaded ? >> >> Thanks, >> Neil > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic [0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c#L222
On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote: > On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote: > > > On 07/24/2017 02:06 PM, Neil Armstrong wrote: > > > > On 07/23/2017 07:03 PM, Joseph Kogut wrote: > > > > > Hi Kevin, > > > > > > > > > > I tested on a P212 reference board, which is currently the only GXL > > > > > based board I have. > > > > > > > > > > Before applying the patch, high activity on the ethernet interface > > > > > would cause the link to break, requiring the interface to be brought > > > > > down and back up before it would work again. After applying the patch, > > > > > I could not get the link to break with any transfers. > > > > > > > > > > _______________________________________________ > > > > > linux-arm-kernel mailing list > > > > > linux-arm-kernel@lists.infradead.org > > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > > > > > > > > > > Hi Joseph, > > > > > > > > [please keep the history of the conversation when replying] > > > > > > > > Is it a original P212 board, or a board based on the P212 ref design ? > > > > > > > > I'm currently testing the v4.13-rc2 on the official P212 board we > > > > received > > > > from Amlogic > > > > and using iperf3 in both directions, I have an issue after a few minutes > > > > running iperf3 with : > > > > > > > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; > > > > done > > > > > > > > That cycles between the two iperf directions. > > > > > > > > After a few minutes, it stalls with : > > > > > > > > Connecting to host 192.168.1.21, port 5201 > > > > [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 > > > > [ ID] Interval Transfer Bandwidth Retr Cwnd > > > > [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes > > > > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > > > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > > > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes > > > > [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > > [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes > > > > > > > > Same kind of test shows no issue on the libretech-cc and the khadas-vim > > In this case, I don't think meson-gxl.dtsi is where you should make your > > change. ahahah, silly me ! I forgot that it was 100MBps PHY. tx delay makes no sense here, 2ns delay would not make much difference on a 25MHz clock Sorry for the confusion > > > > > > > > > > And then, after: > > > > # ifconfig eth0 down > > > > # ifconfig eth0 up > > > > > > > > It cycles between : > > > > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - > > > > 100Mbps/Full - flow control rx/tx > > > > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down > > > > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - > > > > 100Mbps/Full - flow control rx/tx > > > > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down > > > > This does not look like the issue we had on the odroid-c2. > > However, I have seen behavior like this (link down/up flickering) when the > > rgmii > > delays are way off. > > > > Maybe you could try playing with "amlogic,tx-delay-ns" property ? > > we need to change dwmac-meson8b.c so it applies the TX delay also for > RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs, > see: [0] > > > > > > > > > and so on. > > > > > > > > And this patch does not fix this at all. > > > > > > > > It seems to be more a PHY driver issue here. > > > > > > > > Could you share the results with the same command ? > > > > > > > > Neil > > > > > > > > > > I forgot to precise, this issue occurs when the "GXL PHY driver" is > > > disabled, > > > only relying on the > > > Generic PHY Driver. > > > > > > [ 630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic > > > PHY] > > > (mii_bus:phy_addr=0.e40908ff:08, irq=-1) > > > > > > > > > When the PHY driver is loaded the issue disappears, with and without your > > > patch. > > > > > > [ 25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver > > > [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) > > > > > > Could you please check the PHY Driver is loaded ? > > > > > > Thanks, > > > Neil > > > > > > _______________________________________________ > > linux-amlogic mailing list > > linux-amlogic@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-amlogic > > > [0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro > /stmmac/dwmac-meson8b.c#L222
Hello, On Mon, Jul 24, 2017 at 8:32 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote: >> On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: >> > On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote: >> > > On 07/24/2017 02:06 PM, Neil Armstrong wrote: >> > > > On 07/23/2017 07:03 PM, Joseph Kogut wrote: >> > > > > Hi Kevin, >> > > > > >> > > > > I tested on a P212 reference board, which is currently the only GXL >> > > > > based board I have. >> > > > > >> > > > > Before applying the patch, high activity on the ethernet interface >> > > > > would cause the link to break, requiring the interface to be brought >> > > > > down and back up before it would work again. After applying the patch, >> > > > > I could not get the link to break with any transfers. >> > > > > >> > > > > _______________________________________________ >> > > > > linux-arm-kernel mailing list >> > > > > linux-arm-kernel@lists.infradead.org >> > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > > > >> > > > >> > > > Hi Joseph, >> > > > >> > > > [please keep the history of the conversation when replying] >> > > > >> > > > Is it a original P212 board, or a board based on the P212 ref design ? >> > > > >> > > > I'm currently testing the v4.13-rc2 on the official P212 board we >> > > > received >> > > > from Amlogic >> > > > and using iperf3 in both directions, I have an issue after a few minutes >> > > > running iperf3 with : >> > > > >> > > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; >> > > > done >> > > > >> > > > That cycles between the two iperf directions. >> > > > >> > > > After a few minutes, it stalls with : >> > > > >> > > > Connecting to host 192.168.1.21, port 5201 >> > > > [ 4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201 >> > > > [ ID] Interval Transfer Bandwidth Retr Cwnd >> > > > [ 4] 0.00-1.00 sec 1.64 MBytes 13.7 Mbits/sec 2 1.41 KBytes >> > > > [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > > > [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > > > [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes >> > > > [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes >> > > > >> > >> > Same kind of test shows no issue on the libretech-cc and the khadas-vim >> > In this case, I don't think meson-gxl.dtsi is where you should make your >> > change. I am using mainline Kernel on Khadas VIM Pro and have such problems. I did send today an update [0] to my older mailinglist post. > ahahah, silly me ! I forgot that it was 100MBps PHY. > tx delay makes no sense here, 2ns delay would not make much difference on a > 25MHz clock > > Sorry for the confusion > > >> > >> > > > >> > > > And then, after: >> > > > # ifconfig eth0 down >> > > > # ifconfig eth0 up >> > > > >> > > > It cycles between : >> > > > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - >> > > > 100Mbps/Full - flow control rx/tx >> > > > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down >> > > > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - >> > > > 100Mbps/Full - flow control rx/tx >> > > > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down >> > >> > This does not look like the issue we had on the odroid-c2. >> > However, I have seen behavior like this (link down/up flickering) when the >> > rgmii >> > delays are way off. >> > >> > Maybe you could try playing with "amlogic,tx-delay-ns" property ? >> >> we need to change dwmac-meson8b.c so it applies the TX delay also for >> RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs, >> see: [0] >> >> > > > >> > > > and so on. >> > > > >> > > > And this patch does not fix this at all. >> > > > >> > > > It seems to be more a PHY driver issue here. >> > > > >> > > > Could you share the results with the same command ? >> > > > >> > > > Neil >> > > > >> > > >> > > I forgot to precise, this issue occurs when the "GXL PHY driver" is >> > > disabled, >> > > only relying on the >> > > Generic PHY Driver. >> > > >> > > [ 630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic >> > > PHY] >> > > (mii_bus:phy_addr=0.e40908ff:08, irq=-1) >> > > >> > > >> > > When the PHY driver is loaded the issue disappears, with and without your >> > > patch. >> > > >> > > [ 25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver >> > > [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1) >> > > >> > > Could you please check the PHY Driver is loaded ? >> > > >> > > Thanks, >> > > Neil >> > >> > >> > _______________________________________________ >> > linux-amlogic mailing list >> > linux-amlogic@lists.infradead.org >> > http://lists.infradead.org/mailman/listinfo/linux-amlogic >> >> >> [0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro >> /stmmac/dwmac-meson8b.c#L222 > Regards, [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-July/004393.html
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 8d4f3160a0ee..620e8a4f9bb3 100644 --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi @@ -570,6 +570,7 @@ compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22"; reg = <8>; max-speed = <100>; + eee-broken-100tx; }; };
Meson GXL appears to suffer from the same broken eee issue as GXB, originally fixed by feb3cbea0946. This patch disables the broken energy-efficient ethernet for GXL, avoiding the tx link breakage. Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> --- arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 1 + 1 file changed, 1 insertion(+)