2017-07-07 01:33:19

by Joseph Kogut

[permalink] [raw]
Subject: [PATCH] ARM64: meson-gxl: disable broken eee

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 <[email protected]>
---
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


2017-07-22 15:26:06

by Kevin Hilman

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

Hi Joseph,

Joseph Kogut <[email protected]> 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 <[email protected]>

Can you share what platforms you tested to find/fix this problem?

Thanks for the patch!

Kevin

2017-07-23 17:03:43

by Joseph Kogut

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

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.

2017-07-24 12:06:48

by Neil Armstrong

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

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
> [email protected]
> 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

2017-07-24 12:27:37

by Neil Armstrong

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

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
>> [email protected]
>> 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

2017-07-24 16:09:47

by Jerome Brunet

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

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
> > > [email protected]
> > > 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

2017-07-24 18:21:24

by Martin Blumenstingl

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <[email protected]> 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
>> > > [email protected]
>> > > 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
> [email protected]
> 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

2017-07-24 18:32:13

by Jerome Brunet

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote:
> On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <[email protected]> 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
> > > > > [email protected]
> > > > > 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
> > [email protected]
> > 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

2017-07-25 17:03:17

by crow

[permalink] [raw]
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee

Hello,

On Mon, Jul 24, 2017 at 8:32 PM, Jerome Brunet <[email protected]> wrote:
> On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote:
>> On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <[email protected]> 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
>> > > > > [email protected]
>> > > > > 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
>> > [email protected]
>> > 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