* [PATCH] ARM64: meson-gxl: disable broken eee @ 2017-07-07 1:32 Joseph Kogut 2017-07-22 15:26 ` Kevin Hilman 0 siblings, 1 reply; 9+ messages in thread From: Joseph Kogut @ 2017-07-07 1:32 UTC (permalink / raw) To: linux-arm-kernel 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(+) 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; }; }; -- 2.13.2 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-07 1:32 [PATCH] ARM64: meson-gxl: disable broken eee Joseph Kogut @ 2017-07-22 15:26 ` Kevin Hilman 2017-07-23 17:03 ` Joseph Kogut 0 siblings, 1 reply; 9+ messages in thread From: Kevin Hilman @ 2017-07-22 15:26 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-22 15:26 ` Kevin Hilman @ 2017-07-23 17:03 ` Joseph Kogut 2017-07-24 12:06 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: Joseph Kogut @ 2017-07-23 17:03 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-23 17:03 ` Joseph Kogut @ 2017-07-24 12:06 ` Neil Armstrong 2017-07-24 12:26 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2017-07-24 12:06 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-24 12:06 ` Neil Armstrong @ 2017-07-24 12:26 ` Neil Armstrong 2017-07-24 16:09 ` Jerome Brunet 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2017-07-24 12:26 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-24 12:26 ` Neil Armstrong @ 2017-07-24 16:09 ` Jerome Brunet 2017-07-24 18:20 ` Martin Blumenstingl 0 siblings, 1 reply; 9+ messages in thread From: Jerome Brunet @ 2017-07-24 16:09 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-24 16:09 ` Jerome Brunet @ 2017-07-24 18:20 ` Martin Blumenstingl 2017-07-24 18:32 ` Jerome Brunet 0 siblings, 1 reply; 9+ messages in thread From: Martin Blumenstingl @ 2017-07-24 18:20 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-24 18:20 ` Martin Blumenstingl @ 2017-07-24 18:32 ` Jerome Brunet 2017-07-25 17:03 ` crow 0 siblings, 1 reply; 9+ messages in thread From: Jerome Brunet @ 2017-07-24 18:32 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM64: meson-gxl: disable broken eee 2017-07-24 18:32 ` Jerome Brunet @ 2017-07-25 17:03 ` crow 0 siblings, 0 replies; 9+ messages in thread From: crow @ 2017-07-25 17:03 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 at 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-07-25 17:03 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-07-07 1:32 [PATCH] ARM64: meson-gxl: disable broken eee Joseph Kogut 2017-07-22 15:26 ` Kevin Hilman 2017-07-23 17:03 ` Joseph Kogut 2017-07-24 12:06 ` Neil Armstrong 2017-07-24 12:26 ` Neil Armstrong 2017-07-24 16:09 ` Jerome Brunet 2017-07-24 18:20 ` Martin Blumenstingl 2017-07-24 18:32 ` Jerome Brunet 2017-07-25 17:03 ` crow
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).