ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic

netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
@ 2017-06-08 17:30 crow
  2017-06-10  7:29 ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-06-08 17:30 UTC (permalink / raw)
  To: netdev, linux-amlogic

Hi,
I have here two problems with Khadas VIM Pro device and Ethernet.

1) sometimes with the Kernel Linux 4.12-rc4 the Ethernet link is Up
but only 10Mbps.
Don't work (either SSH to device nor over serial console to ping out)
meson8b-dwmac c9410000.ethernet eth0: Link is Up - 10Mbps/Half - flow
control off

Works (if I do ifconfig eth0 down / up):
meson8b-dwmac c9410000.ethernet eth0: Link is Down
meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
control off

Whole log could be found in [0].

2) if downloading an amount of data while connected to device over
SSH, connection will stall and after some minutes SSH session would be
disconnected. Nothing is written in dmesg and ethtool shows me same
values before when Ethernet was working, and after when connection
stall. Whole log can be found in [1]

SSH to device (OK)
  -> Cloning linux git repo...
Cloning into bare repository '/opt/mmcblk1/linux-aarch64-git/linux'...
remote: Counting objects: 5399033, done.
remote: Compressing objects: 100% (1495/1495), done.
Receiving objects:   3% (161971/5399033), 73.20 MiB | 6.19 MiB/s

here the download stalled and SSH connection also stalled but not disconnected

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 8
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: yes
#

after 2 min SSH connection disconnected

over serial console:
# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>From 10.8.8.6 icmp_seq=1 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2060ms
pipe 3
#

nothing in dmesg or in journalctl

also here is helps only to take port down and again up. restarting
networking services fails "timed out".

Regards,


[0] https://defuse.ca/b/jqXqW9Ip
[1] https://defuse.ca/b/bJLOAuX6

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-08 17:30 ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic crow
@ 2017-06-10  7:29 ` crow
  2017-06-10 15:27   ` Andrew Lunn
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-06-10  7:29 UTC (permalink / raw)
  To: netdev, linux-amlogic

Hi,

On Thu, Jun 8, 2017 at 7:30 PM, crow <crow@linux.org.ba> wrote:
> Hi,
> I have here two problems with Khadas VIM Pro device and Ethernet.
>
> 1) sometimes with the Kernel Linux 4.12-rc4 the Ethernet link is Up
> but only 10Mbps.
> Don't work (either SSH to device nor over serial console to ping out)
> meson8b-dwmac c9410000.ethernet eth0: Link is Up - 10Mbps/Half - flow
> control off
>
> Works (if I do ifconfig eth0 down / up):
> meson8b-dwmac c9410000.ethernet eth0: Link is Down
> meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
> control off
>
> Whole log could be found in [0].
>
> 2) if downloading an amount of data while connected to device over
> SSH, connection will stall and after some minutes SSH session would be
> disconnected. Nothing is written in dmesg and ethtool shows me same
> values before when Ethernet was working, and after when connection
> stall. Whole log can be found in [1]
>
> SSH to device (OK)
>   -> Cloning linux git repo...
> Cloning into bare repository '/opt/mmcblk1/linux-aarch64-git/linux'...
> remote: Counting objects: 5399033, done.
> remote: Compressing objects: 100% (1495/1495), done.
> Receiving objects:   3% (161971/5399033), 73.20 MiB | 6.19 MiB/s
>
> here the download stalled and SSH connection also stalled but not disconnected
>
> # ethtool eth0
> Settings for eth0:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>         Supported pause frame use: Symmetric Receive-only
>         Supports auto-negotiation: Yes
>         Advertised link modes:  10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>         Advertised pause frame use: No
>         Advertised auto-negotiation: Yes
>         Link partner advertised link modes:  10baseT/Half 10baseT/Full
>                                              100baseT/Half 100baseT/Full
>         Link partner advertised pause frame use: No
>         Link partner advertised auto-negotiation: Yes
>         Speed: 100Mb/s
>         Duplex: Full
>         Port: MII
>         PHYAD: 8
>         Transceiver: internal
>         Auto-negotiation: on
>         Supports Wake-on: ug
>         Wake-on: d
>         Current message level: 0x0000003f (63)
>                                drv probe link timer ifdown ifup
>         Link detected: yes
> #
>
> after 2 min SSH connection disconnected
>
> over serial console:
> # ping -c3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
>
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2060ms
> pipe 3
> #
>
> nothing in dmesg or in journalctl
>
> also here is helps only to take port down and again up. restarting
> networking services fails "timed out".
>
> Regards,
>
>
> [0] https://defuse.ca/b/jqXqW9Ip
> [1] https://defuse.ca/b/bJLOAuX6


I am posting this only as Information if needed to others who may be
able to check this, as I am not able to do it:

I was told from Neil Armstrong to post PHY register dump information
from eth0, but to use official Khadas VIM Ubuntu image (Amlogic
kernel) and then mainline kernel 4.12-rc4 (which I am running on
ArchLinuxArm).

With custom Amlogic 4.9.26 kernel I was able to git clone linux repository:

Linux Khadas 4.9.26 #1 SMP PREEMPT Sun Jun 4 11:34:23 CST 2017 aarch64
aarch64 aarch64 GNU/Linux

# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0082 40e8 5400 0d80 1000 0000 a900
    fff0 ffff 0000 140a 1407 00ca 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

With custom Amlogic 3.1.14 kernel cloning linux repository was also working

Linux Khadas 3.14.29 #21 SMP PREEMPT Sat May 13 22:10:31 CST 2017
aarch64 aarch64 aarch64 GNU/Linux

# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 00c2 40e8 5400 0803 0000 0000 0009
    fff0 ffff 0000 020a 1407 00ca 0e00 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

This now is register dump when SSH was working and before trying to
clone linux repository on mainline kernel. There is some differences
between mainline kernel and custom amlogic!

Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
2017 aarch64 GNU/Linux

# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000d 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 020a 1407 004a 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

This is register dump once when cloning stops and SSH session
disconnects, there is again some differences even between these two
mainline kernel register dumps (working and when it stops working)

Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
2017 aarch64 GNU/Linux

# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 040a 1407 004a 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

I was told to have a look at the Amlogic PHY driver and check if they
check or set these registers that differs. But as I really don't know
anything about development I am unable to understand this code or to
provide an fix.

These information which I found crucial I got from Martin Blumenstingl
regarding driver "debug" option:
There's no "debug" parameter for meson8b-dwmac because this is only a
few lines of code: [0]
What I should check is probably the PHY register dump (see above) or
debug output from stmmac  [1]. The meson8b-dwmac is just a "SoC
specific configuration + loader" for stmmac.

Also what Martin Blumenstingl wrote is following which is also crucial
for fixing the issue:
Amlogic has given their ethernet PHY driver some updates [2], it now
includes wake-on-lan, and they now have an internal_phy_read_status
which uses reset_internal_phy if there's a link and some error counter
exceeds some magic value.

Regards,

[0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
[1] http://elixir.free-electrons.com/linux/v4.8/source/Documentation/networking/stmmac.txt
[2] https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c#L129

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-10  7:29 ` crow
@ 2017-06-10 15:27   ` Andrew Lunn
  2017-06-11  6:31     ` crow
  2017-06-11 13:43     ` crow
  0 siblings, 2 replies; 13+ messages in thread
From: Andrew Lunn @ 2017-06-10 15:27 UTC (permalink / raw)
  To: crow; +Cc: netdev, linux-amlogic

> Also what Martin Blumenstingl wrote is following which is also crucial
> for fixing the issue:
> Amlogic has given their ethernet PHY driver some updates [2], it now
> includes wake-on-lan, and they now have an internal_phy_read_status
> which uses reset_internal_phy if there's a link and some error counter
> exceeds some magic value.

Hi Crow

You could probably just drop the Amlogic driver into mainline and see
if it works better. If that solves your problem, we can look at
merging the changes.

	Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-10 15:27   ` Andrew Lunn
@ 2017-06-11  6:31     ` crow
  2017-07-26 19:27       ` Jerome Brunet
  2017-06-11 13:43     ` crow
  1 sibling, 1 reply; 13+ messages in thread
From: crow @ 2017-06-11  6:31 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, linux-amlogic

Hi Andrew,

On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Also what Martin Blumenstingl wrote is following which is also crucial
>> for fixing the issue:
>> Amlogic has given their ethernet PHY driver some updates [2], it now
>> includes wake-on-lan, and they now have an internal_phy_read_status
>> which uses reset_internal_phy if there's a link and some error counter
>> exceeds some magic value.
>
> Hi Crow
>
> You could probably just drop the Amlogic driver into mainline and see
> if it works better. If that solves your problem, we can look at
> merging the changes.
>
>         Andrew

Thank your for the suggestion, and thanks Martin to explaining me over
IRC what actually I should do.

I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
replaced drivers/net/phy/meson-gxl.c with
https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c

But this did not solve the issue. As soon as i start git clone i lose
network connection to device (no session timeout/disconnect this time,
but I am unable to reconnect over SSH or to get OK ping replay back).

Here are the tests:
Linux khadasvimpro 4.12.0-rc4-4-ARCH #1 SMP Sun Jun 11 03:39:21 CEST
2017 aarch64 GNU/Linux

# modinfo meson_gxl
filename:
/lib/modules/4.12.0-rc4-4-ARCH/kernel/drivers/net/phy/meson-gxl.ko.gz
license:        GPL
author:         Neil Armstrong <narmstrong@baylibre.com>
author:         Baoqi wang
description:    Amlogic Meson GXL Internal PHY driver
alias:          mdio:0000000110000001010001000000????
depends:
intree:         Y
vermagic:       4.12.0-rc4-4-ARCH SMP mod_unload aarch64
#
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 040a 1407 004a 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
$

over SSH startet following but it stall already at 0%:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 5948690, done.
remote: Compressing objects: 100% (124799/124799), done.
Receiving objects:   0% (11668/5948690), 2.27 MiB | 4.52 MiB/s

shows timeout while trying to sync with NTP server:

# journalctl -f
systemd-timesyncd[299]: Timed out waiting for reply from
83.68.137.76:123 (2.at.pool.ntp.org).
systemd-timesyncd[299]: Timed out waiting for reply from
86.59.113.114:123 (2.at.pool.ntp.org).

while still not working dump the register:
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000d 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 040a 1407 0000 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

# ifconfig eth0 down && ifconfig eth0 up
# dmesg -T | tail -n 10
[Sun Jun 11 07:40:34 2017] meson8b-dwmac c9410000.ethernet eth0:
device MAC address 00:15:18:01:81:31
[Sun Jun 11 07:40:34 2017] random: crng init done
[Sun Jun 11 07:40:34 2017] Meson GXL Internal PHY 0.e40908ff:08:
attached PHY driver [Meson GXL Internal PHY]
(mii_bus:phy_addr=0.e40908ff:08, irq=-1)
[Sun Jun 11 07:40:34 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
not supported by HW
[Sun Jun 11 07:40:36 2017] brcmfmac: brcmf_c_preinit_dcmds: Firmware
version = wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID
01-6a2c8ad4
[Sun Jun 11 07:40:36 2017] meson8b-dwmac c9410000.ethernet eth0: Link
is Up - 100Mbps/Full - flow control off
[Sun Jun 11 07:41:23 2017] EXT4-fs (mmcblk1p1): mounted filesystem
with ordered data mode. Opts: (null)
[Sun Jun 11 07:54:28 2017] Meson GXL Internal PHY 0.e40908ff:08:
attached PHY driver [Meson GXL Internal PHY]
(mii_bus:phy_addr=0.e40908ff:08, irq=-1)
[Sun Jun 11 07:54:28 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
not supported by HW
[Sun Jun 11 07:54:30 2017] meson8b-dwmac c9410000.ethernet eth0: Link
is Up - 100Mbps/Full - flow control off
#

then I took eth0 and wlan0 up (same ArchLinuxArm with same mainline
kernel same place where the files are stored eMMC) and this was
working so it should not be the ArchLinuxArm which makes problem, and
did same git clone as with custom Amlogic kernel (3.1.4 and 4.9.26
under Khadas Ubuntu image) and test was successfully:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 5948690, done.
remote: Compressing objects: 100% (124799/124799), done.
remote: Total 5948690 (delta 427756), reused 549521 (delta 425675)
Receiving objects: 100% (5948690/5948690), 1.21 GiB | 4.94 MiB/s, done.
Resolving deltas: 100% (4961965/4961965), done.
Checking out files: 100% (59844/59844), done.
$

Regards,

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-11  6:31     ` crow
@ 2017-07-26 19:27       ` Jerome Brunet
  0 siblings, 0 replies; 13+ messages in thread
From: Jerome Brunet @ 2017-07-26 19:27 UTC (permalink / raw)
  To: crow, Andrew Lunn; +Cc: netdev, linux-amlogic

On Sun, 2017-06-11 at 08:31 +0200, crow wrote:
> Hi Andrew,
> 
> On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > Also what Martin Blumenstingl wrote is following which is also crucial
> > > for fixing the issue:
> > > Amlogic has given their ethernet PHY driver some updates [2], it now
> > > includes wake-on-lan, and they now have an internal_phy_read_status
> > > which uses reset_internal_phy if there's a link and some error counter
> > > exceeds some magic value.
> > 
> > Hi Crow
> > 
> > You could probably just drop the Amlogic driver into mainline and see
> > if it works better. If that solves your problem, we can look at
> > merging the changes.
> > 
> >         Andrew
> 
> Thank your for the suggestion, and thanks Martin to explaining me over
> IRC what actually I should do.
> 
> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
> replaced drivers/net/phy/meson-gxl.c with
> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/a
> mlogic.c
> 
> But this did not solve the issue. As soon as i start git clone i lose
> network connection to device (no session timeout/disconnect this time,
> but I am unable to reconnect over SSH or to get OK ping replay back).
> 
> Here are the tests:
> Linux khadasvimpro 4.12.0-rc4-4-ARCH #1 SMP Sun Jun 11 03:39:21 CEST
> 2017 aarch64 GNU/Linux
> 
> # modinfo meson_gxl
> filename:
> /lib/modules/4.12.0-rc4-4-ARCH/kernel/drivers/net/phy/meson-gxl.ko.gz
> license:        GPL
> author:         Neil Armstrong <narmstrong@baylibre.com>
> author:         Baoqi wang
> description:    Amlogic Meson GXL Internal PHY driver
> alias:          mdio:0000000110000001010001000000????
> depends:
> intree:         Y
> vermagic:       4.12.0-rc4-4-ARCH SMP mod_unload aarch64
> #
> # mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok

Hum, 1000Mbps Half duplex looks duplex looks suspicious
The PHY is supposed to be a 10/100, right ? or did I miss something ?

>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 c1e1 000f 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 040a 1407 004a 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> $
> 
> over SSH startet following but it stall already at 0%:
> 
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> stable.git
> Cloning into 'linux-stable'...
> remote: Counting objects: 5948690, done.
> remote: Compressing objects: 100% (124799/124799), done.
> Receiving objects:   0% (11668/5948690), 2.27 MiB | 4.52 MiB/s
> 
> shows timeout while trying to sync with NTP server:
> 
> # journalctl -f
> systemd-timesyncd[299]: Timed out waiting for reply from
> 83.68.137.76:123 (2.at.pool.ntp.org).
> systemd-timesyncd[299]: Timed out waiting for reply from
> 86.59.113.114:123 (2.at.pool.ntp.org).
> 
> while still not working dump the register:
> # mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok
>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 c1e1 000d 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 040a 1407 0000 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> #
> 
> # ifconfig eth0 down && ifconfig eth0 up
> # dmesg -T | tail -n 10
> [Sun Jun 11 07:40:34 2017] meson8b-dwmac c9410000.ethernet eth0:
> device MAC address 00:15:18:01:81:31
> [Sun Jun 11 07:40:34 2017] random: crng init done
> [Sun Jun 11 07:40:34 2017] Meson GXL Internal PHY 0.e40908ff:08:
> attached PHY driver [Meson GXL Internal PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> [Sun Jun 11 07:40:34 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
> not supported by HW
> [Sun Jun 11 07:40:36 2017] brcmfmac: brcmf_c_preinit_dcmds: Firmware
> version = wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID
> 01-6a2c8ad4
> [Sun Jun 11 07:40:36 2017] meson8b-dwmac c9410000.ethernet eth0: Link
> is Up - 100Mbps/Full - flow control off
> [Sun Jun 11 07:41:23 2017] EXT4-fs (mmcblk1p1): mounted filesystem
> with ordered data mode. Opts: (null)
> [Sun Jun 11 07:54:28 2017] Meson GXL Internal PHY 0.e40908ff:08:
> attached PHY driver [Meson GXL Internal PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> [Sun Jun 11 07:54:28 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
> not supported by HW
> [Sun Jun 11 07:54:30 2017] meson8b-dwmac c9410000.ethernet eth0: Link
> is Up - 100Mbps/Full - flow control off
> #
> 
> then I took eth0 and wlan0 up (same ArchLinuxArm with same mainline
> kernel same place where the files are stored eMMC) and this was
> working so it should not be the ArchLinuxArm which makes problem, and
> did same git clone as with custom Amlogic kernel (3.1.4 and 4.9.26
> under Khadas Ubuntu image) and test was successfully:
> 
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> stable.git
> Cloning into 'linux-stable'...
> remote: Counting objects: 5948690, done.
> remote: Compressing objects: 100% (124799/124799), done.
> remote: Total 5948690 (delta 427756), reused 549521 (delta 425675)
> Receiving objects: 100% (5948690/5948690), 1.21 GiB | 4.94 MiB/s, done.
> Resolving deltas: 100% (4961965/4961965), done.
> Checking out files: 100% (59844/59844), done.
> $
> 
> Regards,
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-10 15:27   ` Andrew Lunn
  2017-06-11  6:31     ` crow
@ 2017-06-11 13:43     ` crow
  2017-06-11 15:21       ` Andrew Lunn
  1 sibling, 1 reply; 13+ messages in thread
From: crow @ 2017-06-11 13:43 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, linux-amlogic

Hi Andrew

On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Also what Martin Blumenstingl wrote is following which is also crucial
>> for fixing the issue:
>> Amlogic has given their ethernet PHY driver some updates [2], it now
>> includes wake-on-lan, and they now have an internal_phy_read_status
>> which uses reset_internal_phy if there's a link and some error counter
>> exceeds some magic value.
>
> Hi Crow
>
> You could probably just drop the Amlogic driver into mainline and see
> if it works better. If that solves your problem, we can look at
> merging the changes.
>
>         Andrew


Please ignore my previus email as I used wrong kernel (not the patched
one, see the modinfo).

Thank your for the suggestion, and thanks Martin to explaining me over
IRC what actually I should do.

I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
replaced drivers/net/phy/meson-gxl.c with
https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c

But this did not solve the issue. As soon as i start git clone i lose
network connection to device (no session timeout/disconnect this time,
but I am unable to reconnect over SSH or to get OK ping replay back).

Linux khadasvimpro 4.12.0-rc4-4-ARCH #1 SMP Sun Jun 11 14:33:40 CEST
2017 aarch64 GNU/Linux

# modinfo meson_gxl
filename:
/lib/modules/4.12.0-rc4-4-ARCH/kernel/drivers/net/phy/meson-gxl.ko.gz
license:        GPL
author:         Yizhou Jiang
description:    amlogic internal ethernet phy driver
alias:          mdio:0000000110000001010001000000????
depends:
intree:         Y
vermagic:       4.12.0-rc4-4-ARCH SMP mod_unload aarch64
#

# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0082 40e8 5400 0d80 1000 0000 a900
    fff0 ffff 0000 130a 1407 00ca 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#


over SSH startet following but it stall already at 1%:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 5948690, done.
remote: Compressing objects: 100% (124799/124799), done.
Receiving objects:   1% (110361/5948690), 48.02 MiB | 6.54 MiB/s


journalctl shows timeout while trying to sync with NTP server:
systemd-timesyncd[292]: Timed out waiting for reply from
91.206.8.36:123 (2.at.pool.ntp.org).
systemd-timesyncd[292]: Timed out waiting for reply from
131.130.251.107:123 (2.at.pool.ntp.org).

ping to this device from other client: 100% packet loss

dumping register after stall state
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000d 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0082 40e8 5400 0d80 1000 0000 a900
    fff0 ffff 0000 130a 1407 0000 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

after taking eth0 down and up, I am able to login to device over SSH
again, and ping from other devices in network to this device are all
OK.

# ifconfig eth0 down && ifconfig eth0 up
# dmesg -T | tail -n 10
[Sun Jun 11 15:03:02 2017] internal phy init
[Sun Jun 11 15:03:02 2017] internal phy init
[Sun Jun 11 15:03:02 2017] amlogic internal phy 0.e40908ff:08:
attached PHY driver [amlogic internal phy]
(mii_bus:phy_addr=0.e40908ff:08, irq=-1)
[Sun Jun 11 15:03:02 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
not supported by HW
[Sun Jun 11 15:03:03 2017] wol_reg12[12]==0, error
[Sun Jun 11 15:03:04 2017] meson8b-dwmac c9410000.ethernet eth0: Link
is Up - 100Mbps/Full - flow control off

[Sun Jun 11 15:10:38 2017] internal phy init
[Sun Jun 11 15:10:38 2017] internal phy init
[Sun Jun 11 15:10:38 2017] amlogic internal phy 0.e40908ff:08:
attached PHY driver [amlogic internal phy]
(mii_bus:phy_addr=0.e40908ff:08, irq=-1)
[Sun Jun 11 15:10:38 2017] meson8b-dwmac c9410000.ethernet eth0: PTP
not supported by HW
[Sun Jun 11 15:10:39 2017] wol_reg12[12]==0, error
[Sun Jun 11 15:10:40 2017] meson8b-dwmac c9410000.ethernet eth0: Link
is Up - 100Mbps/Full - flow control off

then I took eth0 and wlan0 up (same ArchLinuxArm with same mainline
kernel same place where the files are stored eMMC) and this was
working so it should not be the ArchLinuxArm which makes problem, and
did same git clone as with custom Amlogic kernel (3.1.4 and 4.9.26
under Khadas Ubuntu image) and test was successfully:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 5948690, done.
remote: Compressing objects: 100% (124799/124799), done.
remote: Total 5948690 (delta 427756), reused 549521 (delta 425675)
Receiving objects: 100% (5948690/5948690), 1.21 GiB | 2.85 MiB/s, done.
Resolving deltas: 100% (4961965/4961965), done.
Checking out files: 100% (59844/59844), done.
$

Regards,

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-11 13:43     ` crow
@ 2017-06-11 15:21       ` Andrew Lunn
  2017-06-11 17:03         ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Lunn @ 2017-06-11 15:21 UTC (permalink / raw)
  To: crow; +Cc: netdev, linux-amlogic

> Thank your for the suggestion, and thanks Martin to explaining me over
> IRC what actually I should do.
> 
> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
> replaced drivers/net/phy/meson-gxl.c with
> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
> 
> But this did not solve the issue. As soon as i start git clone i lose
> network connection to device (no session timeout/disconnect this time,
> but I am unable to reconnect over SSH or to get OK ping replay back).

So this shows it is more than a PHY problem. The Ethernet MAC driver
is probably also part of the problem.

Are there any mainline kernels which work O.K?

    Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-11 15:21       ` Andrew Lunn
@ 2017-06-11 17:03         ` crow
  2017-06-15 14:40           ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-06-11 17:03 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, linux-amlogic

Hi Andrew,

On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Thank your for the suggestion, and thanks Martin to explaining me over
>> IRC what actually I should do.
>>
>> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>> replaced drivers/net/phy/meson-gxl.c with
>> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>>
>> But this did not solve the issue. As soon as i start git clone i lose
>> network connection to device (no session timeout/disconnect this time,
>> but I am unable to reconnect over SSH or to get OK ping replay back).
>

1) First problem reported I can't reproduce anymore, every reboot/cold
boot with mainline kernel the Ethernet speed is detected as
"100Mbps/Full" , but as seen in first post there was this issue.

2) see below

> So this shows it is more than a PHY problem. The Ethernet MAC driver
> is probably also part of the problem.

There are some stmmac fixes [1] in soon to be rc5, compiled current
master (without amlogic.c) with the fixes but for me the issue still
persist. I will compile once released rc5 with amlogic.c and report
back.

> Are there any mainline kernels which work O.K?

Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
but without success.

>     Andrew

[1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372ae310818a6292

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-11 17:03         ` crow
@ 2017-06-15 14:40           ` crow
  2017-06-27 17:14             ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-06-15 14:40 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, open list:ARM/Amlogic Meson...

Hi,

On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
> Hi Andrew,
>
> On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> Thank your for the suggestion, and thanks Martin to explaining me over
>>> IRC what actually I should do.
>>>
>>> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>>> replaced drivers/net/phy/meson-gxl.c with
>>> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>>>
>>> But this did not solve the issue. As soon as i start git clone i lose
>>> network connection to device (no session timeout/disconnect this time,
>>> but I am unable to reconnect over SSH or to get OK ping replay back).
>>
>
> 1) First problem reported I can't reproduce anymore, every reboot/cold
> boot with mainline kernel the Ethernet speed is detected as
> "100Mbps/Full" , but as seen in first post there was this issue.

Once I did setup u-boot to have network in u-boot and did just an ping
to activate network. And after boot Ethernet was detected as 10Mbps.
But again was not able to reproduce it. I double check that I have 5E
cable.

in u-boot Ethernet is detected as below
kvim#ping x.x.x.x
Speed: 100, full duplex
Using dwmac.c9410000 device
host x.x.x.x is alive
kvim#

then I let ArchLinuxArm to boot and found out I can't connect to
device over SSH. Check over serial console and found:

# dmesg | tail -n 10
[    8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
address 00:15:18:01:81:31
[    8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
irq=-1)
[    8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
[   10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
[   10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
10Mbps/Half - flow control off
# uname -a
Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
2017 aarch64 GNU/Linux
#
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: no autonegotiation,, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 0001 0005 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 000a 1407 0040 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#
# ifconfig eth0 down && ifconfig eth0 up
[ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
irq=-1)
[ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
[ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
100Mbps/Full - flow control off
#
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 020a 1407 00ca 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
#

2) see below
> 2) see below
>
>> So this shows it is more than a PHY problem. The Ethernet MAC driver
>> is probably also part of the problem.
>
> There are some stmmac fixes [1] in soon to be rc5, compiled current
> master (without amlogic.c) with the fixes but for me the issue still
> persist. I will compile once released rc5 with amlogic.c and report
> back.
>
>> Are there any mainline kernels which work O.K?
>
> Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
> but without success.

I did test many Kernel builds but all test have failed when
downloading bigger files / doing git clone.
As Martin Blumenstingl suggested I start with first commit where
Khadas VIM support was added [0]. Then also Neil Armstrong suggested
[1]. Then all 4.12-rc1 - rc5.
Martin Blumenstingl have also found himself that: "I can reproduce the
Ethernet problem (tried downloading a 1GiB test file from leaseweb,
network got stuck after downloading ~70 MiB)". He suggested that I
should "play with the settings on your switch (disable jumbo frames,
etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
connected on this same Switch port does not have any problem
downloading big files or doing git clone, as well as Khadas VIM with
Amlogic kernel. Also jumbo frames are not enabled, switch does have
only standard settings.

I also get questioned which qdisc I use:
And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
$ tc -s -p qdisc
qdisc noqueue 0: dev lo root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc mq 0: dev eth0 root
 Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
 backlog 0b 0p requeues 18
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
 backlog 0b 0p requeues 18
  maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
  new_flows_len 0 old_flows_len 0
$ pacman -Qi systemd
Name            : systemd
Version         : 232-8
Description     : system and service manager
Architecture    : aarch64
...
$


Regards,

>>     Andrew
>
> [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372ae310818a6292

[0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8652da71369e
[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux-amlogic/+/v4.12/integ

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-15 14:40           ` crow
@ 2017-06-27 17:14             ` crow
  2017-07-25 16:56               ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-06-27 17:14 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, open list:ARM/Amlogic Meson...

Hi,
There are other user reporting same issue while using mainline kernel
but using Ubuntu, so this is for sure not Distribution related. For me
see the [0]. I hope someone would get time after 4.12 release to try
fix this issue.

Regards,

[0] http://forum.khadas.com/t/ubuntu-server-rom-linux-mainline-v170624-pre-alpha-version-emmc-installation/803/12

On Thu, Jun 15, 2017 at 4:40 PM, crow <crow@linux.org.ba> wrote:
> Hi,
>
> On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
>> Hi Andrew,
>>
>> On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>>> Thank your for the suggestion, and thanks Martin to explaining me over
>>>> IRC what actually I should do.
>>>>
>>>> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>>>> replaced drivers/net/phy/meson-gxl.c with
>>>> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>>>>
>>>> But this did not solve the issue. As soon as i start git clone i lose
>>>> network connection to device (no session timeout/disconnect this time,
>>>> but I am unable to reconnect over SSH or to get OK ping replay back).
>>>
>>
>> 1) First problem reported I can't reproduce anymore, every reboot/cold
>> boot with mainline kernel the Ethernet speed is detected as
>> "100Mbps/Full" , but as seen in first post there was this issue.
>
> Once I did setup u-boot to have network in u-boot and did just an ping
> to activate network. And after boot Ethernet was detected as 10Mbps.
> But again was not able to reproduce it. I double check that I have 5E
> cable.
>
> in u-boot Ethernet is detected as below
> kvim#ping x.x.x.x
> Speed: 100, full duplex
> Using dwmac.c9410000 device
> host x.x.x.x is alive
> kvim#
>
> then I let ArchLinuxArm to boot and found out I can't connect to
> device over SSH. Check over serial console and found:
>
> # dmesg | tail -n 10
> [    8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
> address 00:15:18:01:81:31
> [    8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
> driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
> irq=-1)
> [    8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
> [   10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
> wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
> [   10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> 10Mbps/Half - flow control off
> # uname -a
> Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
> 2017 aarch64 GNU/Linux
> #
> # mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: no autonegotiation,, link ok
>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 0001 0005 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 000a 1407 0040 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> #
> # ifconfig eth0 down && ifconfig eth0 up
> [ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
> driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
> irq=-1)
> [ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
> [ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> 100Mbps/Full - flow control off
> #
> # mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok
>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 c1e1 000f 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 020a 1407 00ca 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> #
>
> 2) see below
>> 2) see below
>>
>>> So this shows it is more than a PHY problem. The Ethernet MAC driver
>>> is probably also part of the problem.
>>
>> There are some stmmac fixes [1] in soon to be rc5, compiled current
>> master (without amlogic.c) with the fixes but for me the issue still
>> persist. I will compile once released rc5 with amlogic.c and report
>> back.
>>
>>> Are there any mainline kernels which work O.K?
>>
>> Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
>> but without success.
>
> I did test many Kernel builds but all test have failed when
> downloading bigger files / doing git clone.
> As Martin Blumenstingl suggested I start with first commit where
> Khadas VIM support was added [0]. Then also Neil Armstrong suggested
> [1]. Then all 4.12-rc1 - rc5.
> Martin Blumenstingl have also found himself that: "I can reproduce the
> Ethernet problem (tried downloading a 1GiB test file from leaseweb,
> network got stuck after downloading ~70 MiB)". He suggested that I
> should "play with the settings on your switch (disable jumbo frames,
> etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
> connected on this same Switch port does not have any problem
> downloading big files or doing git clone, as well as Khadas VIM with
> Amlogic kernel. Also jumbo frames are not enabled, switch does have
> only standard settings.
>
> I also get questioned which qdisc I use:
> And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
> $ tc -s -p qdisc
> qdisc noqueue 0: dev lo root refcnt 2
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
> qdisc mq 0: dev eth0 root
>  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>  backlog 0b 0p requeues 18
> qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
> 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>  backlog 0b 0p requeues 18
>   maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
> $ pacman -Qi systemd
> Name            : systemd
> Version         : 232-8
> Description     : system and service manager
> Architecture    : aarch64
> ...
> $
>
>
> Regards,
>
>>>     Andrew
>>
>> [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372ae310818a6292
>
> [0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8652da71369e
> [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux-amlogic/+/v4.12/integ

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-06-27 17:14             ` crow
@ 2017-07-25 16:56               ` crow
  2017-07-26 19:32                 ` Jerome Brunet
  0 siblings, 1 reply; 13+ messages in thread
From: crow @ 2017-07-25 16:56 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev, open list:ARM/Amlogic Meson...

Hi,
Today I did test on ArchLinuxArm the Kernel v4.13-rc2. On downloading
the linux git source the network will eventually get stalled. Here are
the information

Over SSH (network works).

[root@alarm ~]# uname -a
Linux alarm 4.13.0-rc2-1-ARCH #1 SMP Mon Jul 24 20:02:50 MDT 2017
aarch64 GNU/Linux
[root@alarm ~]# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 000a 1407 004a 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
[root@alarm ~]# ethtool -S eth0
NIC statistics:
     mmc_tx_octetcount_gb: 0
     mmc_tx_framecount_gb: 0
     mmc_tx_broadcastframe_g: 0
     mmc_tx_multicastframe_g: 0
     mmc_tx_64_octets_gb: 0
     mmc_tx_65_to_127_octets_gb: 0
     mmc_tx_128_to_255_octets_gb: 0
     mmc_tx_256_to_511_octets_gb: 0
     mmc_tx_512_to_1023_octets_gb: 0
     mmc_tx_1024_to_max_octets_gb: 0
     mmc_tx_unicast_gb: 0
     mmc_tx_multicast_gb: 0
     mmc_tx_broadcast_gb: 0
     mmc_tx_underflow_error: 0
     mmc_tx_singlecol_g: 0
     mmc_tx_multicol_g: 0
     mmc_tx_deferred: 0
     mmc_tx_latecol: 0
     mmc_tx_exesscol: 0
     mmc_tx_carrier_error: 0
     mmc_tx_octetcount_g: 0
     mmc_tx_framecount_g: 0
     mmc_tx_excessdef: 0
     mmc_tx_pause_frame: 0
     mmc_tx_vlan_frame_g: 0
     mmc_rx_framecount_gb: 133
     mmc_rx_octetcount_gb: 16646
     mmc_rx_octetcount_g: 16646
     mmc_rx_broadcastframe_g: 9
     mmc_rx_multicastframe_g: 22
     mmc_rx_crc_error: 0
     mmc_rx_align_error: 0
     mmc_rx_run_error: 0
     mmc_rx_jabber_error: 0
     mmc_rx_undersize_g: 0
     mmc_rx_oversize_g: 0
     mmc_rx_64_octets_gb: 45
     mmc_rx_65_to_127_octets_gb: 64
     mmc_rx_128_to_255_octets_gb: 13
     mmc_rx_256_to_511_octets_gb: 7
     mmc_rx_512_to_1023_octets_gb: 4
     mmc_rx_1024_to_max_octets_gb: 0
     mmc_rx_unicast_g: 102
     mmc_rx_length_error: 0
     mmc_rx_autofrangetype: 0
     mmc_rx_pause_frames: 0
     mmc_rx_fifo_overflow: 0
     mmc_rx_vlan_frames_gb: 0
     mmc_rx_watchdog_error: 0
     mmc_rx_ipc_intr_mask: 1073692671
     mmc_rx_ipc_intr: 0
     mmc_rx_ipv4_gd: 117
     mmc_rx_ipv4_hderr: 0
     mmc_rx_ipv4_nopay: 0
     mmc_rx_ipv4_frag: 0
     mmc_rx_ipv4_udsbl: 0
     mmc_rx_ipv4_gd_octets: 12585
     mmc_rx_ipv4_hderr_octets: 0
     mmc_rx_ipv4_nopay_octets: 0
     mmc_rx_ipv4_frag_octets: 0
     mmc_rx_ipv4_udsbl_octets: 0
     mmc_rx_ipv6_gd_octets: 104
     mmc_rx_ipv6_hderr_octets: 0
     mmc_rx_ipv6_nopay_octets: 0
     mmc_rx_ipv6_gd: 1
     mmc_rx_ipv6_hderr: 0
     mmc_rx_ipv6_nopay: 0
     mmc_rx_udp_gd: 31
     mmc_rx_udp_err: 0
     mmc_rx_tcp_gd: 85
     mmc_rx_tcp_err: 0
     mmc_rx_icmp_gd: 2
     mmc_rx_icmp_err: 0
     mmc_rx_udp_gd_octets: 2963
     mmc_rx_udp_err_octets: 0
     mmc_rx_tcp_gd_octets: 7254
     mmc_rx_tcp_err_octets: 0
     mmc_rx_icmp_gd_octets: 92
     mmc_rx_icmp_err_octets: 0
     tx_underflow: 0
     tx_carrier: 0
     tx_losscarrier: 0
     vlan_tag: 0
     tx_deferred: 0
     tx_vlan: 0
     tx_jabber: 0
     tx_frame_flushed: 0
     tx_payload_error: 0
     tx_ip_header_error: 0
     rx_desc: 0
     sa_filter_fail: 0
     overflow_error: 0
     ipc_csum_error: 0
     rx_collision: 0
     rx_crc_errors: 0
     dribbling_bit: 0
     rx_length: 0
     rx_mii: 0
     rx_multicast: 0
     rx_gmac_overflow: 0
     rx_watchdog: 0
     da_rx_filter_fail: 0
     sa_rx_filter_fail: 0
     rx_missed_cntr: 0
     rx_overflow_cntr: 0
     rx_vlan: 0
     tx_undeflow_irq: 0
     tx_process_stopped_irq: 0
     tx_jabber_irq: 0
     rx_overflow_irq: 0
     rx_buf_unav_irq: 0
     rx_process_stopped_irq: 0
     rx_watchdog_irq: 0
     tx_early_irq: 0
     fatal_bus_error_irq: 0
     rx_early_irq: 0
     threshold: 1
     tx_pkt_n: 83
     rx_pkt_n: 133
     normal_irq_n: 130
     rx_normal_irq_n: 129
     napi_poll: 130
     tx_normal_irq_n: 1
     tx_clean: 192
     tx_set_ic_bit: 1
     irq_receive_pmt_irq_n: 0
     mmc_tx_irq_n: 0
     mmc_rx_irq_n: 0
     mmc_rx_csum_offload_irq_n: 0
     irq_tx_path_in_lpi_mode_n: 72
     irq_tx_path_exit_lpi_mode_n: 72
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
     phy_eee_wakeup_error_n: 65535
     ip_hdr_err: 0
     ip_payload_err: 0
     ip_csum_bypassed: 0
     ipv4_pkt_rcvd: 0
     ipv6_pkt_rcvd: 0
     no_ptp_rx_msg_type_ext: 0
     ptp_rx_msg_type_sync: 0
     ptp_rx_msg_type_follow_up: 0
     ptp_rx_msg_type_delay_req: 0
     ptp_rx_msg_type_delay_resp: 0
     ptp_rx_msg_type_pdelay_req: 0
     ptp_rx_msg_type_pdelay_resp: 0
     ptp_rx_msg_type_pdelay_follow_up: 0
     ptp_rx_msg_type_announce: 0
     ptp_rx_msg_type_management: 0
     ptp_rx_msg_pkt_reserved_type: 0
     ptp_frame_type: 0
     ptp_ver: 0
     timestamp_dropped: 0
     av_pkt_rcvd: 0
     av_tagged_pkt_rcvd: 0
     vlan_tag_priority_val: 0
     l3_filter_match: 0
     l4_filter_match: 0
     l3_l4_filter_no_match: 0
     irq_pcs_ane_n: 0
     irq_pcs_link_n: 0
     irq_rgmii_n: 0
     mtl_tx_status_fifo_full: 0
     mtl_tx_fifo_not_empty: 0
     mmtl_fifo_ctrl: 0
     mtl_tx_fifo_read_ctrl_write: 0
     mtl_tx_fifo_read_ctrl_wait: 0
     mtl_tx_fifo_read_ctrl_read: 0
     mtl_tx_fifo_read_ctrl_idle: 0
     mac_tx_in_pause: 0
     mac_tx_frame_ctrl_xfer: 0
     mac_tx_frame_ctrl_idle: 0
     mac_tx_frame_ctrl_wait: 0
     mac_tx_frame_ctrl_pause: 0
     mac_gmii_tx_proto_engine: 0
     mtl_rx_fifo_fill_level_full: 0
     mtl_rx_fifo_fill_above_thresh: 0
     mtl_rx_fifo_fill_below_thresh: 0
     mtl_rx_fifo_fill_level_empty: 0
     mtl_rx_fifo_read_ctrl_flush: 0
     mtl_rx_fifo_read_ctrl_read_data: 0
     mtl_rx_fifo_read_ctrl_status: 0
     mtl_rx_fifo_read_ctrl_idle: 0
     mtl_rx_fifo_ctrl_active: 0
     mac_rx_frame_ctrl_fifo: 0
     mac_gmii_rx_proto_engine: 0
     tx_tso_frames: 0
     tx_tso_nfrags: 0
[root@alarm ~]#




[root@alarm opt]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Cloning into 'linux-stable'...
remote: Counting objects: 6071472, done.
remote: Compressing objects: 100% (961861/961861), done.
Receiving objects:   0% (22798/6071472), 9.12 MiB | 3.47 MiB/s



Over serial console:
journalctl -f
alarm systemd-timesyncd[256]: Timed out waiting for reply from
144.76.197.108:123 (2.arch.pool.ntp.org).

[root@alarm ~]# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
>From 10.8.8.6 icmp_seq=2 Destination Host Unreachable
>From 10.8.8.6 icmp_seq=3 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2047ms
pipe 3
[root@alarm ~]#
[root@alarm ~]# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000d 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0002 40e8 5400 1c1c 0000 0000 aaaa
    fff0 ffff 0000 000a 1407 0000 0000 105a
  product info: vendor 00:60:51, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD
[root@alarm ~]# ethtool -S eth0
NIC statistics:
     mmc_tx_octetcount_gb: 0
     mmc_tx_framecount_gb: 0
     mmc_tx_broadcastframe_g: 0
     mmc_tx_multicastframe_g: 0
     mmc_tx_64_octets_gb: 0
     mmc_tx_65_to_127_octets_gb: 0
     mmc_tx_128_to_255_octets_gb: 0
     mmc_tx_256_to_511_octets_gb: 0
     mmc_tx_512_to_1023_octets_gb: 0
     mmc_tx_1024_to_max_octets_gb: 0
     mmc_tx_unicast_gb: 0
     mmc_tx_multicast_gb: 0
     mmc_tx_broadcast_gb: 0
     mmc_tx_underflow_error: 0
     mmc_tx_singlecol_g: 0
     mmc_tx_multicol_g: 0
     mmc_tx_deferred: 0
     mmc_tx_latecol: 0
     mmc_tx_exesscol: 0
     mmc_tx_carrier_error: 0
     mmc_tx_octetcount_g: 0
     mmc_tx_framecount_g: 0
     mmc_tx_excessdef: 0
     mmc_tx_pause_frame: 0
     mmc_tx_vlan_frame_g: 0
     mmc_rx_framecount_gb: 14959
     mmc_rx_octetcount_gb: 20761536
     mmc_rx_octetcount_g: 20761536
     mmc_rx_broadcastframe_g: 22
     mmc_rx_multicastframe_g: 64
     mmc_rx_crc_error: 0
     mmc_rx_align_error: 0
     mmc_rx_run_error: 0
     mmc_rx_jabber_error: 0
     mmc_rx_undersize_g: 0
     mmc_rx_oversize_g: 0
     mmc_rx_64_octets_gb: 495
     mmc_rx_65_to_127_octets_gb: 658
     mmc_rx_128_to_255_octets_gb: 73
     mmc_rx_256_to_511_octets_gb: 63
     mmc_rx_512_to_1023_octets_gb: 124
     mmc_rx_1024_to_max_octets_gb: 13546
     mmc_rx_unicast_g: 14873
     mmc_rx_length_error: 0
     mmc_rx_autofrangetype: 0
     mmc_rx_pause_frames: 0
     mmc_rx_fifo_overflow: 0
     mmc_rx_vlan_frames_gb: 0
     mmc_rx_watchdog_error: 0
     mmc_rx_ipc_intr_mask: 2147385342
     mmc_rx_ipc_intr: 0
     mmc_rx_ipv4_gd: 14725
     mmc_rx_ipv4_hderr: 0
     mmc_rx_ipv4_nopay: 0
     mmc_rx_ipv4_frag: 0
     mmc_rx_ipv4_udsbl: 0
     mmc_rx_ipv4_gd_octets: 20476749
     mmc_rx_ipv4_hderr_octets: 0
     mmc_rx_ipv4_nopay_octets: 0
     mmc_rx_ipv4_frag_octets: 0
     mmc_rx_ipv4_udsbl_octets: 0
     mmc_rx_ipv6_gd_octets: 312
     mmc_rx_ipv6_hderr_octets: 0
     mmc_rx_ipv6_nopay_octets: 0
     mmc_rx_ipv6_gd: 3
     mmc_rx_ipv6_hderr: 0
     mmc_rx_ipv6_nopay: 0
     mmc_rx_udp_gd: 51
     mmc_rx_udp_err: 0
     mmc_rx_tcp_gd: 14673
     mmc_rx_tcp_err: 0
     mmc_rx_icmp_gd: 4
     mmc_rx_icmp_err: 0
     mmc_rx_udp_gd_octets: 3924
     mmc_rx_udp_err_octets: 0
     mmc_rx_tcp_gd_octets: 20178297
     mmc_rx_tcp_err_octets: 0
     mmc_rx_icmp_gd_octets: 220
     mmc_rx_icmp_err_octets: 0
     tx_underflow: 0
     tx_carrier: 0
     tx_losscarrier: 0
     vlan_tag: 0
     tx_deferred: 0
     tx_vlan: 0
     tx_jabber: 0
     tx_frame_flushed: 0
     tx_payload_error: 0
     tx_ip_header_error: 0
     rx_desc: 0
     sa_filter_fail: 0
     overflow_error: 0
     ipc_csum_error: 0
     rx_collision: 0
     rx_crc_errors: 0
     dribbling_bit: 0
     rx_length: 0
     rx_mii: 0
     rx_multicast: 0
     rx_gmac_overflow: 0
     rx_watchdog: 0
     da_rx_filter_fail: 0
     sa_rx_filter_fail: 0
     rx_missed_cntr: 0
     rx_overflow_cntr: 0
     rx_vlan: 0
     tx_undeflow_irq: 0
     tx_process_stopped_irq: 0
     tx_jabber_irq: 0
     rx_overflow_irq: 0
     rx_buf_unav_irq: 0
     rx_process_stopped_irq: 0
     rx_watchdog_irq: 0
     tx_early_irq: 0
     fatal_bus_error_irq: 0
     rx_early_irq: 6
     threshold: 1
     tx_pkt_n: 3709
     rx_pkt_n: 12926
     normal_irq_n: 4594
     rx_normal_irq_n: 4537
     napi_poll: 4597
     tx_normal_irq_n: 57
     tx_clean: 5109
     tx_set_ic_bit: 59
     irq_receive_pmt_irq_n: 0
     mmc_tx_irq_n: 0
     mmc_rx_irq_n: 0
     mmc_rx_csum_offload_irq_n: 0
     irq_tx_path_in_lpi_mode_n: 2921
     irq_tx_path_exit_lpi_mode_n: 2920
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
     phy_eee_wakeup_error_n: 65535
     ip_hdr_err: 0
     ip_payload_err: 0
     ip_csum_bypassed: 0
     ipv4_pkt_rcvd: 0
     ipv6_pkt_rcvd: 0
     no_ptp_rx_msg_type_ext: 0
     ptp_rx_msg_type_sync: 0
     ptp_rx_msg_type_follow_up: 0
     ptp_rx_msg_type_delay_req: 0
     ptp_rx_msg_type_delay_resp: 0
     ptp_rx_msg_type_pdelay_req: 0
     ptp_rx_msg_type_pdelay_resp: 0
     ptp_rx_msg_type_pdelay_follow_up: 0
     ptp_rx_msg_type_announce: 0
     ptp_rx_msg_type_management: 0
     ptp_rx_msg_pkt_reserved_type: 0
     ptp_frame_type: 0
     ptp_ver: 0
     timestamp_dropped: 0
     av_pkt_rcvd: 0
     av_tagged_pkt_rcvd: 0
     vlan_tag_priority_val: 0
     l3_filter_match: 0
     l4_filter_match: 0
     l3_l4_filter_no_match: 0
     irq_pcs_ane_n: 0
     irq_pcs_link_n: 0
     irq_rgmii_n: 0
     mtl_tx_status_fifo_full: 0
     mtl_tx_fifo_not_empty: 0
     mmtl_fifo_ctrl: 0
     mtl_tx_fifo_read_ctrl_write: 0
     mtl_tx_fifo_read_ctrl_wait: 0
     mtl_tx_fifo_read_ctrl_read: 0
     mtl_tx_fifo_read_ctrl_idle: 0
     mac_tx_in_pause: 0
     mac_tx_frame_ctrl_xfer: 0
     mac_tx_frame_ctrl_idle: 0
     mac_tx_frame_ctrl_wait: 0
     mac_tx_frame_ctrl_pause: 0
     mac_gmii_tx_proto_engine: 0
     mtl_rx_fifo_fill_level_full: 0
     mtl_rx_fifo_fill_above_thresh: 0
     mtl_rx_fifo_fill_below_thresh: 0
     mtl_rx_fifo_fill_level_empty: 0
     mtl_rx_fifo_read_ctrl_flush: 0
     mtl_rx_fifo_read_ctrl_read_data: 0
     mtl_rx_fifo_read_ctrl_status: 0
     mtl_rx_fifo_read_ctrl_idle: 0
     mtl_rx_fifo_ctrl_active: 0
     mac_rx_frame_ctrl_fifo: 0
     mac_gmii_rx_proto_engine: 0
     tx_tso_frames: 0
     tx_tso_nfrags: 0
[root@alarm ~]#
[root@alarm ~]# ifconfig eth0 down && ifconfig eth0 up
Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL
Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
control off
[root@alarm ~]#



whole dmesg [1]. there are some messages like: mdio-mux-mmioreg
c883455c.eth-phy-mux: failed to register mdio-mux bus
/soc/periphs@c8834000/eth-phy-mux

[1] https://defuse.ca/b/s2NpyJlw

Regards,


On Tue, Jun 27, 2017 at 7:14 PM, crow <crow@linux.org.ba> wrote:
> Hi,
> There are other user reporting same issue while using mainline kernel
> but using Ubuntu, so this is for sure not Distribution related. For me
> see the [0]. I hope someone would get time after 4.12 release to try
> fix this issue.
>
> Regards,
>
> [0] http://forum.khadas.com/t/ubuntu-server-rom-linux-mainline-v170624-pre-alpha-version-emmc-installation/803/12
>
> On Thu, Jun 15, 2017 at 4:40 PM, crow <crow@linux.org.ba> wrote:
>> Hi,
>>
>> On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
>>> Hi Andrew,
>>>
>>> On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>>>> Thank your for the suggestion, and thanks Martin to explaining me over
>>>>> IRC what actually I should do.
>>>>>
>>>>> I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>>>>> replaced drivers/net/phy/meson-gxl.c with
>>>>> https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethernet/phy/amlogic.c
>>>>>
>>>>> But this did not solve the issue. As soon as i start git clone i lose
>>>>> network connection to device (no session timeout/disconnect this time,
>>>>> but I am unable to reconnect over SSH or to get OK ping replay back).
>>>>
>>>
>>> 1) First problem reported I can't reproduce anymore, every reboot/cold
>>> boot with mainline kernel the Ethernet speed is detected as
>>> "100Mbps/Full" , but as seen in first post there was this issue.
>>
>> Once I did setup u-boot to have network in u-boot and did just an ping
>> to activate network. And after boot Ethernet was detected as 10Mbps.
>> But again was not able to reproduce it. I double check that I have 5E
>> cable.
>>
>> in u-boot Ethernet is detected as below
>> kvim#ping x.x.x.x
>> Speed: 100, full duplex
>> Using dwmac.c9410000 device
>> host x.x.x.x is alive
>> kvim#
>>
>> then I let ArchLinuxArm to boot and found out I can't connect to
>> device over SSH. Check over serial console and found:
>>
>> # dmesg | tail -n 10
>> [    8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
>> address 00:15:18:01:81:31
>> [    8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> irq=-1)
>> [    8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
>> [   10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>> wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
>> [   10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> 10Mbps/Half - flow control off
>> # uname -a
>> Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
>> 2017 aarch64 GNU/Linux
>> #
>> # mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: no autonegotiation,, link ok
>>   registers for MII PHY 8:
>>     1000 782d 0181 4400 01e1 0001 0005 2001
>>     ffff ffff ffff ffff ffff ffff ffff ffff
>>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>>     fff0 ffff 0000 000a 1407 0040 0000 105a
>>   product info: vendor 00:60:51, model 0 rev 0
>>   basic mode:   autonegotiation enabled
>>   basic status: autonegotiation complete, link ok
>>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> #
>> # ifconfig eth0 down && ifconfig eth0 up
>> [ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> irq=-1)
>> [ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
>> [ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> 100Mbps/Full - flow control off
>> #
>> # mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-HD flow-control, link ok
>>   registers for MII PHY 8:
>>     1000 782d 0181 4400 01e1 c1e1 000f 2001
>>     ffff ffff ffff ffff ffff ffff ffff ffff
>>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>>     fff0 ffff 0000 020a 1407 00ca 0000 105a
>>   product info: vendor 00:60:51, model 0 rev 0
>>   basic mode:   autonegotiation enabled
>>   basic status: autonegotiation complete, link ok
>>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> #
>>
>> 2) see below
>>> 2) see below
>>>
>>>> So this shows it is more than a PHY problem. The Ethernet MAC driver
>>>> is probably also part of the problem.
>>>
>>> There are some stmmac fixes [1] in soon to be rc5, compiled current
>>> master (without amlogic.c) with the fixes but for me the issue still
>>> persist. I will compile once released rc5 with amlogic.c and report
>>> back.
>>>
>>>> Are there any mainline kernels which work O.K?
>>>
>>> Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
>>> but without success.
>>
>> I did test many Kernel builds but all test have failed when
>> downloading bigger files / doing git clone.
>> As Martin Blumenstingl suggested I start with first commit where
>> Khadas VIM support was added [0]. Then also Neil Armstrong suggested
>> [1]. Then all 4.12-rc1 - rc5.
>> Martin Blumenstingl have also found himself that: "I can reproduce the
>> Ethernet problem (tried downloading a 1GiB test file from leaseweb,
>> network got stuck after downloading ~70 MiB)". He suggested that I
>> should "play with the settings on your switch (disable jumbo frames,
>> etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
>> connected on this same Switch port does not have any problem
>> downloading big files or doing git clone, as well as Khadas VIM with
>> Amlogic kernel. Also jumbo frames are not enabled, switch does have
>> only standard settings.
>>
>> I also get questioned which qdisc I use:
>> And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
>> $ tc -s -p qdisc
>> qdisc noqueue 0: dev lo root refcnt 2
>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
>> qdisc mq 0: dev eth0 root
>>  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>>  backlog 0b 0p requeues 18
>> qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
>> 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>>  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>>  backlog 0b 0p requeues 18
>>   maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
>>   new_flows_len 0 old_flows_len 0
>> $ pacman -Qi systemd
>> Name            : systemd
>> Version         : 232-8
>> Description     : system and service manager
>> Architecture    : aarch64
>> ...
>> $
>>
>>
>> Regards,
>>
>>>>     Andrew
>>>
>>> [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372ae310818a6292
>>
>> [0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8652da71369e
>> [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux-amlogic/+/v4.12/integ

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-07-25 16:56               ` crow
@ 2017-07-26 19:32                 ` Jerome Brunet
  2017-08-02 12:39                   ` crow
  0 siblings, 1 reply; 13+ messages in thread
From: Jerome Brunet @ 2017-07-26 19:32 UTC (permalink / raw)
  To: crow, Andrew Lunn; +Cc: netdev, open list:ARM/Amlogic Meson...

On Tue, 2017-07-25 at 18:56 +0200, crow wrote:
> Hi,
> Today I did test on ArchLinuxArm the Kernel v4.13-rc2. On downloading
> the linux git source the network will eventually get stalled. Here are
> the information
> 
> Over SSH (network works).
> 
> [root@alarm ~]# uname -a
> Linux alarm 4.13.0-rc2-1-ARCH #1 SMP Mon Jul 24 20:02:50 MDT 2017
> aarch64 GNU/Linux
> [root@alarm ~]# mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok

[Replying again on the last thread :) ]
This 1000BaseT Half Duplex looks suspucious if the PHY is supposed to be a
10/100Mbps

>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 c1e1 000f 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 000a 1407 004a 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> [root@alarm ~]# ethtool -S eth0
> NIC statistics:
>      mmc_tx_octetcount_gb: 0
>      mmc_tx_framecount_gb: 0
>      mmc_tx_broadcastframe_g: 0
>      mmc_tx_multicastframe_g: 0
>      mmc_tx_64_octets_gb: 0
>      mmc_tx_65_to_127_octets_gb: 0
>      mmc_tx_128_to_255_octets_gb: 0
>      mmc_tx_256_to_511_octets_gb: 0
>      mmc_tx_512_to_1023_octets_gb: 0
>      mmc_tx_1024_to_max_octets_gb: 0
>      mmc_tx_unicast_gb: 0
>      mmc_tx_multicast_gb: 0
>      mmc_tx_broadcast_gb: 0
>      mmc_tx_underflow_error: 0
>      mmc_tx_singlecol_g: 0
>      mmc_tx_multicol_g: 0
>      mmc_tx_deferred: 0
>      mmc_tx_latecol: 0
>      mmc_tx_exesscol: 0
>      mmc_tx_carrier_error: 0
>      mmc_tx_octetcount_g: 0
>      mmc_tx_framecount_g: 0
>      mmc_tx_excessdef: 0
>      mmc_tx_pause_frame: 0
>      mmc_tx_vlan_frame_g: 0
>      mmc_rx_framecount_gb: 133
>      mmc_rx_octetcount_gb: 16646
>      mmc_rx_octetcount_g: 16646
>      mmc_rx_broadcastframe_g: 9
>      mmc_rx_multicastframe_g: 22
>      mmc_rx_crc_error: 0
>      mmc_rx_align_error: 0
>      mmc_rx_run_error: 0
>      mmc_rx_jabber_error: 0
>      mmc_rx_undersize_g: 0
>      mmc_rx_oversize_g: 0
>      mmc_rx_64_octets_gb: 45
>      mmc_rx_65_to_127_octets_gb: 64
>      mmc_rx_128_to_255_octets_gb: 13
>      mmc_rx_256_to_511_octets_gb: 7
>      mmc_rx_512_to_1023_octets_gb: 4
>      mmc_rx_1024_to_max_octets_gb: 0
>      mmc_rx_unicast_g: 102
>      mmc_rx_length_error: 0
>      mmc_rx_autofrangetype: 0
>      mmc_rx_pause_frames: 0
>      mmc_rx_fifo_overflow: 0
>      mmc_rx_vlan_frames_gb: 0
>      mmc_rx_watchdog_error: 0
>      mmc_rx_ipc_intr_mask: 1073692671
>      mmc_rx_ipc_intr: 0
>      mmc_rx_ipv4_gd: 117
>      mmc_rx_ipv4_hderr: 0
>      mmc_rx_ipv4_nopay: 0
>      mmc_rx_ipv4_frag: 0
>      mmc_rx_ipv4_udsbl: 0
>      mmc_rx_ipv4_gd_octets: 12585
>      mmc_rx_ipv4_hderr_octets: 0
>      mmc_rx_ipv4_nopay_octets: 0
>      mmc_rx_ipv4_frag_octets: 0
>      mmc_rx_ipv4_udsbl_octets: 0
>      mmc_rx_ipv6_gd_octets: 104
>      mmc_rx_ipv6_hderr_octets: 0
>      mmc_rx_ipv6_nopay_octets: 0
>      mmc_rx_ipv6_gd: 1
>      mmc_rx_ipv6_hderr: 0
>      mmc_rx_ipv6_nopay: 0
>      mmc_rx_udp_gd: 31
>      mmc_rx_udp_err: 0
>      mmc_rx_tcp_gd: 85
>      mmc_rx_tcp_err: 0
>      mmc_rx_icmp_gd: 2
>      mmc_rx_icmp_err: 0
>      mmc_rx_udp_gd_octets: 2963
>      mmc_rx_udp_err_octets: 0
>      mmc_rx_tcp_gd_octets: 7254
>      mmc_rx_tcp_err_octets: 0
>      mmc_rx_icmp_gd_octets: 92
>      mmc_rx_icmp_err_octets: 0
>      tx_underflow: 0
>      tx_carrier: 0
>      tx_losscarrier: 0
>      vlan_tag: 0
>      tx_deferred: 0
>      tx_vlan: 0
>      tx_jabber: 0
>      tx_frame_flushed: 0
>      tx_payload_error: 0
>      tx_ip_header_error: 0
>      rx_desc: 0
>      sa_filter_fail: 0
>      overflow_error: 0
>      ipc_csum_error: 0
>      rx_collision: 0
>      rx_crc_errors: 0
>      dribbling_bit: 0
>      rx_length: 0
>      rx_mii: 0
>      rx_multicast: 0
>      rx_gmac_overflow: 0
>      rx_watchdog: 0
>      da_rx_filter_fail: 0
>      sa_rx_filter_fail: 0
>      rx_missed_cntr: 0
>      rx_overflow_cntr: 0
>      rx_vlan: 0
>      tx_undeflow_irq: 0
>      tx_process_stopped_irq: 0
>      tx_jabber_irq: 0
>      rx_overflow_irq: 0
>      rx_buf_unav_irq: 0
>      rx_process_stopped_irq: 0
>      rx_watchdog_irq: 0
>      tx_early_irq: 0
>      fatal_bus_error_irq: 0
>      rx_early_irq: 0
>      threshold: 1
>      tx_pkt_n: 83
>      rx_pkt_n: 133
>      normal_irq_n: 130
>      rx_normal_irq_n: 129
>      napi_poll: 130
>      tx_normal_irq_n: 1
>      tx_clean: 192
>      tx_set_ic_bit: 1
>      irq_receive_pmt_irq_n: 0
>      mmc_tx_irq_n: 0
>      mmc_rx_irq_n: 0
>      mmc_rx_csum_offload_irq_n: 0
>      irq_tx_path_in_lpi_mode_n: 72
>      irq_tx_path_exit_lpi_mode_n: 72
>      irq_rx_path_in_lpi_mode_n: 0
>      irq_rx_path_exit_lpi_mode_n: 0
>      phy_eee_wakeup_error_n: 65535
>      ip_hdr_err: 0
>      ip_payload_err: 0
>      ip_csum_bypassed: 0
>      ipv4_pkt_rcvd: 0
>      ipv6_pkt_rcvd: 0
>      no_ptp_rx_msg_type_ext: 0
>      ptp_rx_msg_type_sync: 0
>      ptp_rx_msg_type_follow_up: 0
>      ptp_rx_msg_type_delay_req: 0
>      ptp_rx_msg_type_delay_resp: 0
>      ptp_rx_msg_type_pdelay_req: 0
>      ptp_rx_msg_type_pdelay_resp: 0
>      ptp_rx_msg_type_pdelay_follow_up: 0
>      ptp_rx_msg_type_announce: 0
>      ptp_rx_msg_type_management: 0
>      ptp_rx_msg_pkt_reserved_type: 0
>      ptp_frame_type: 0
>      ptp_ver: 0
>      timestamp_dropped: 0
>      av_pkt_rcvd: 0
>      av_tagged_pkt_rcvd: 0
>      vlan_tag_priority_val: 0
>      l3_filter_match: 0
>      l4_filter_match: 0
>      l3_l4_filter_no_match: 0
>      irq_pcs_ane_n: 0
>      irq_pcs_link_n: 0
>      irq_rgmii_n: 0
>      mtl_tx_status_fifo_full: 0
>      mtl_tx_fifo_not_empty: 0
>      mmtl_fifo_ctrl: 0
>      mtl_tx_fifo_read_ctrl_write: 0
>      mtl_tx_fifo_read_ctrl_wait: 0
>      mtl_tx_fifo_read_ctrl_read: 0
>      mtl_tx_fifo_read_ctrl_idle: 0
>      mac_tx_in_pause: 0
>      mac_tx_frame_ctrl_xfer: 0
>      mac_tx_frame_ctrl_idle: 0
>      mac_tx_frame_ctrl_wait: 0
>      mac_tx_frame_ctrl_pause: 0
>      mac_gmii_tx_proto_engine: 0
>      mtl_rx_fifo_fill_level_full: 0
>      mtl_rx_fifo_fill_above_thresh: 0
>      mtl_rx_fifo_fill_below_thresh: 0
>      mtl_rx_fifo_fill_level_empty: 0
>      mtl_rx_fifo_read_ctrl_flush: 0
>      mtl_rx_fifo_read_ctrl_read_data: 0
>      mtl_rx_fifo_read_ctrl_status: 0
>      mtl_rx_fifo_read_ctrl_idle: 0
>      mtl_rx_fifo_ctrl_active: 0
>      mac_rx_frame_ctrl_fifo: 0
>      mac_gmii_rx_proto_engine: 0
>      tx_tso_frames: 0
>      tx_tso_nfrags: 0
> [root@alarm ~]#
> 
> 
> 
> 
> [root@alarm opt]# git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Cloning into 'linux-stable'...
> remote: Counting objects: 6071472, done.
> remote: Compressing objects: 100% (961861/961861), done.
> Receiving objects:   0% (22798/6071472), 9.12 MiB | 3.47 MiB/s
> 
> 
> 
> Over serial console:
> journalctl -f
> alarm systemd-timesyncd[256]: Timed out waiting for reply from
> 144.76.197.108:123 (2.arch.pool.ntp.org).
> 
> [root@alarm ~]# ping -c3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
> From 10.8.8.6 icmp_seq=2 Destination Host Unreachable
> From 10.8.8.6 icmp_seq=3 Destination Host Unreachable
> 
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2047ms
> pipe 3
> [root@alarm ~]#
> [root@alarm ~]# mii-tool -vvv eth0
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok
>   registers for MII PHY 8:
>     1000 782d 0181 4400 01e1 c1e1 000d 2001
>     ffff ffff ffff ffff ffff ffff ffff ffff
>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>     fff0 ffff 0000 000a 1407 0000 0000 105a
>   product info: vendor 00:60:51, model 0 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> [root@alarm ~]# ethtool -S eth0
> NIC statistics:
>      mmc_tx_octetcount_gb: 0
>      mmc_tx_framecount_gb: 0
>      mmc_tx_broadcastframe_g: 0
>      mmc_tx_multicastframe_g: 0
>      mmc_tx_64_octets_gb: 0
>      mmc_tx_65_to_127_octets_gb: 0
>      mmc_tx_128_to_255_octets_gb: 0
>      mmc_tx_256_to_511_octets_gb: 0
>      mmc_tx_512_to_1023_octets_gb: 0
>      mmc_tx_1024_to_max_octets_gb: 0
>      mmc_tx_unicast_gb: 0
>      mmc_tx_multicast_gb: 0
>      mmc_tx_broadcast_gb: 0
>      mmc_tx_underflow_error: 0
>      mmc_tx_singlecol_g: 0
>      mmc_tx_multicol_g: 0
>      mmc_tx_deferred: 0
>      mmc_tx_latecol: 0
>      mmc_tx_exesscol: 0
>      mmc_tx_carrier_error: 0
>      mmc_tx_octetcount_g: 0
>      mmc_tx_framecount_g: 0
>      mmc_tx_excessdef: 0
>      mmc_tx_pause_frame: 0
>      mmc_tx_vlan_frame_g: 0
>      mmc_rx_framecount_gb: 14959
>      mmc_rx_octetcount_gb: 20761536
>      mmc_rx_octetcount_g: 20761536
>      mmc_rx_broadcastframe_g: 22
>      mmc_rx_multicastframe_g: 64
>      mmc_rx_crc_error: 0
>      mmc_rx_align_error: 0
>      mmc_rx_run_error: 0
>      mmc_rx_jabber_error: 0
>      mmc_rx_undersize_g: 0
>      mmc_rx_oversize_g: 0
>      mmc_rx_64_octets_gb: 495
>      mmc_rx_65_to_127_octets_gb: 658
>      mmc_rx_128_to_255_octets_gb: 73
>      mmc_rx_256_to_511_octets_gb: 63
>      mmc_rx_512_to_1023_octets_gb: 124
>      mmc_rx_1024_to_max_octets_gb: 13546
>      mmc_rx_unicast_g: 14873
>      mmc_rx_length_error: 0
>      mmc_rx_autofrangetype: 0
>      mmc_rx_pause_frames: 0
>      mmc_rx_fifo_overflow: 0
>      mmc_rx_vlan_frames_gb: 0
>      mmc_rx_watchdog_error: 0
>      mmc_rx_ipc_intr_mask: 2147385342
>      mmc_rx_ipc_intr: 0
>      mmc_rx_ipv4_gd: 14725
>      mmc_rx_ipv4_hderr: 0
>      mmc_rx_ipv4_nopay: 0
>      mmc_rx_ipv4_frag: 0
>      mmc_rx_ipv4_udsbl: 0
>      mmc_rx_ipv4_gd_octets: 20476749
>      mmc_rx_ipv4_hderr_octets: 0
>      mmc_rx_ipv4_nopay_octets: 0
>      mmc_rx_ipv4_frag_octets: 0
>      mmc_rx_ipv4_udsbl_octets: 0
>      mmc_rx_ipv6_gd_octets: 312
>      mmc_rx_ipv6_hderr_octets: 0
>      mmc_rx_ipv6_nopay_octets: 0
>      mmc_rx_ipv6_gd: 3
>      mmc_rx_ipv6_hderr: 0
>      mmc_rx_ipv6_nopay: 0
>      mmc_rx_udp_gd: 51
>      mmc_rx_udp_err: 0
>      mmc_rx_tcp_gd: 14673
>      mmc_rx_tcp_err: 0
>      mmc_rx_icmp_gd: 4
>      mmc_rx_icmp_err: 0
>      mmc_rx_udp_gd_octets: 3924
>      mmc_rx_udp_err_octets: 0
>      mmc_rx_tcp_gd_octets: 20178297
>      mmc_rx_tcp_err_octets: 0
>      mmc_rx_icmp_gd_octets: 220
>      mmc_rx_icmp_err_octets: 0
>      tx_underflow: 0
>      tx_carrier: 0
>      tx_losscarrier: 0
>      vlan_tag: 0
>      tx_deferred: 0
>      tx_vlan: 0
>      tx_jabber: 0
>      tx_frame_flushed: 0
>      tx_payload_error: 0
>      tx_ip_header_error: 0
>      rx_desc: 0
>      sa_filter_fail: 0
>      overflow_error: 0
>      ipc_csum_error: 0
>      rx_collision: 0
>      rx_crc_errors: 0
>      dribbling_bit: 0
>      rx_length: 0
>      rx_mii: 0
>      rx_multicast: 0
>      rx_gmac_overflow: 0
>      rx_watchdog: 0
>      da_rx_filter_fail: 0
>      sa_rx_filter_fail: 0
>      rx_missed_cntr: 0
>      rx_overflow_cntr: 0
>      rx_vlan: 0
>      tx_undeflow_irq: 0
>      tx_process_stopped_irq: 0
>      tx_jabber_irq: 0
>      rx_overflow_irq: 0
>      rx_buf_unav_irq: 0
>      rx_process_stopped_irq: 0
>      rx_watchdog_irq: 0
>      tx_early_irq: 0
>      fatal_bus_error_irq: 0
>      rx_early_irq: 6
>      threshold: 1
>      tx_pkt_n: 3709
>      rx_pkt_n: 12926
>      normal_irq_n: 4594
>      rx_normal_irq_n: 4537
>      napi_poll: 4597
>      tx_normal_irq_n: 57
>      tx_clean: 5109
>      tx_set_ic_bit: 59
>      irq_receive_pmt_irq_n: 0
>      mmc_tx_irq_n: 0
>      mmc_rx_irq_n: 0
>      mmc_rx_csum_offload_irq_n: 0
>      irq_tx_path_in_lpi_mode_n: 2921
>      irq_tx_path_exit_lpi_mode_n: 2920
>      irq_rx_path_in_lpi_mode_n: 0
>      irq_rx_path_exit_lpi_mode_n: 0
>      phy_eee_wakeup_error_n: 65535
>      ip_hdr_err: 0
>      ip_payload_err: 0
>      ip_csum_bypassed: 0
>      ipv4_pkt_rcvd: 0
>      ipv6_pkt_rcvd: 0
>      no_ptp_rx_msg_type_ext: 0
>      ptp_rx_msg_type_sync: 0
>      ptp_rx_msg_type_follow_up: 0
>      ptp_rx_msg_type_delay_req: 0
>      ptp_rx_msg_type_delay_resp: 0
>      ptp_rx_msg_type_pdelay_req: 0
>      ptp_rx_msg_type_pdelay_resp: 0
>      ptp_rx_msg_type_pdelay_follow_up: 0
>      ptp_rx_msg_type_announce: 0
>      ptp_rx_msg_type_management: 0
>      ptp_rx_msg_pkt_reserved_type: 0
>      ptp_frame_type: 0
>      ptp_ver: 0
>      timestamp_dropped: 0
>      av_pkt_rcvd: 0
>      av_tagged_pkt_rcvd: 0
>      vlan_tag_priority_val: 0
>      l3_filter_match: 0
>      l4_filter_match: 0
>      l3_l4_filter_no_match: 0
>      irq_pcs_ane_n: 0
>      irq_pcs_link_n: 0
>      irq_rgmii_n: 0
>      mtl_tx_status_fifo_full: 0
>      mtl_tx_fifo_not_empty: 0
>      mmtl_fifo_ctrl: 0
>      mtl_tx_fifo_read_ctrl_write: 0
>      mtl_tx_fifo_read_ctrl_wait: 0
>      mtl_tx_fifo_read_ctrl_read: 0
>      mtl_tx_fifo_read_ctrl_idle: 0
>      mac_tx_in_pause: 0
>      mac_tx_frame_ctrl_xfer: 0
>      mac_tx_frame_ctrl_idle: 0
>      mac_tx_frame_ctrl_wait: 0
>      mac_tx_frame_ctrl_pause: 0
>      mac_gmii_tx_proto_engine: 0
>      mtl_rx_fifo_fill_level_full: 0
>      mtl_rx_fifo_fill_above_thresh: 0
>      mtl_rx_fifo_fill_below_thresh: 0
>      mtl_rx_fifo_fill_level_empty: 0
>      mtl_rx_fifo_read_ctrl_flush: 0
>      mtl_rx_fifo_read_ctrl_read_data: 0
>      mtl_rx_fifo_read_ctrl_status: 0
>      mtl_rx_fifo_read_ctrl_idle: 0
>      mtl_rx_fifo_ctrl_active: 0
>      mac_rx_frame_ctrl_fifo: 0
>      mac_gmii_rx_proto_engine: 0
>      tx_tso_frames: 0
>      tx_tso_nfrags: 0
> [root@alarm ~]#
> [root@alarm ~]# ifconfig eth0 down && ifconfig eth0 up
> Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL
> Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
> meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
> control off
> [root@alarm ~]#
> 
> 
> 
> whole dmesg [1]. there are some messages like: mdio-mux-mmioreg
> c883455c.eth-phy-mux: failed to register mdio-mux bus
> /soc/periphs@c8834000/eth-phy-mux
> 
> [1] https://defuse.ca/b/s2NpyJlw
> 
> Regards,
> 
> 
> On Tue, Jun 27, 2017 at 7:14 PM, crow <crow@linux.org.ba> wrote:
> > Hi,
> > There are other user reporting same issue while using mainline kernel
> > but using Ubuntu, so this is for sure not Distribution related. For me
> > see the [0]. I hope someone would get time after 4.12 release to try
> > fix this issue.
> > 
> > Regards,
> > 
> > [0] http://forum.khadas.com/t/ubuntu-server-rom-linux-mainline-v170624-pre-a
> > lpha-version-emmc-installation/803/12
> > 
> > On Thu, Jun 15, 2017 at 4:40 PM, crow <crow@linux.org.ba> wrote:
> > > Hi,
> > > 
> > > On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
> > > > Hi Andrew,
> > > > 
> > > > On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > > > > Thank your for the suggestion, and thanks Martin to explaining me
> > > > > > over
> > > > > > IRC what actually I should do.
> > > > > > 
> > > > > > I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
> > > > > > replaced drivers/net/phy/meson-gxl.c with
> > > > > > https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethe
> > > > > > rnet/phy/amlogic.c
> > > > > > 
> > > > > > But this did not solve the issue. As soon as i start git clone i
> > > > > > lose
> > > > > > network connection to device (no session timeout/disconnect this
> > > > > > time,
> > > > > > but I am unable to reconnect over SSH or to get OK ping replay
> > > > > > back).
> > > > 
> > > > 1) First problem reported I can't reproduce anymore, every reboot/cold
> > > > boot with mainline kernel the Ethernet speed is detected as
> > > > "100Mbps/Full" , but as seen in first post there was this issue.
> > > 
> > > Once I did setup u-boot to have network in u-boot and did just an ping
> > > to activate network. And after boot Ethernet was detected as 10Mbps.
> > > But again was not able to reproduce it. I double check that I have 5E
> > > cable.
> > > 
> > > in u-boot Ethernet is detected as below
> > > kvim#ping x.x.x.x
> > > Speed: 100, full duplex
> > > Using dwmac.c9410000 device
> > > host x.x.x.x is alive
> > > kvim#
> > > 
> > > then I let ArchLinuxArm to boot and found out I can't connect to
> > > device over SSH. Check over serial console and found:
> > > 
> > > # dmesg | tail -n 10
> > > [    8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
> > > address 00:15:18:01:81:31
> > > [    8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
> > > irq=-1)
> > > [    8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
> > > HW
> > > [   10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
> > > wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
> > > [   10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > > 10Mbps/Half - flow control off
> > > # uname -a
> > > Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
> > > 2017 aarch64 GNU/Linux
> > > #
> > > # mii-tool -vvv eth0
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: no autonegotiation,, link ok
> > >   registers for MII PHY 8:
> > >     1000 782d 0181 4400 01e1 0001 0005 2001
> > >     ffff ffff ffff ffff ffff ffff ffff ffff
> > >     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
> > >     fff0 ffff 0000 000a 1407 0040 0000 105a
> > >   product info: vendor 00:60:51, model 0 rev 0
> > >   basic mode:   autonegotiation enabled
> > >   basic status: autonegotiation complete, link ok
> > >   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> > > 10baseT-FD 10baseT-HD
> > >   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> > > 10baseT-FD 10baseT-HD
> > > #
> > > # ifconfig eth0 down && ifconfig eth0 up
> > > [ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
> > > irq=-1)
> > > [ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
> > > HW
> > > [ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > > 100Mbps/Full - flow control off
> > > #
> > > # mii-tool -vvv eth0
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 1000baseT-HD flow-control, link ok
> > >   registers for MII PHY 8:
> > >     1000 782d 0181 4400 01e1 c1e1 000f 2001
> > >     ffff ffff ffff ffff ffff ffff ffff ffff
> > >     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
> > >     fff0 ffff 0000 020a 1407 00ca 0000 105a
> > >   product info: vendor 00:60:51, model 0 rev 0
> > >   basic mode:   autonegotiation enabled
> > >   basic status: autonegotiation complete, link ok
> > >   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> > > 10baseT-FD 10baseT-HD
> > >   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> > > 10baseT-FD 10baseT-HD
> > >   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> > > 10baseT-FD 10baseT-HD
> > > #
> > > 
> > > 2) see below
> > > > 2) see below
> > > > 
> > > > > So this shows it is more than a PHY problem. The Ethernet MAC driver
> > > > > is probably also part of the problem.
> > > > 
> > > > There are some stmmac fixes [1] in soon to be rc5, compiled current
> > > > master (without amlogic.c) with the fixes but for me the issue still
> > > > persist. I will compile once released rc5 with amlogic.c and report
> > > > back.
> > > > 
> > > > > Are there any mainline kernels which work O.K?
> > > > 
> > > > Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
> > > > but without success.
> > > 
> > > I did test many Kernel builds but all test have failed when
> > > downloading bigger files / doing git clone.
> > > As Martin Blumenstingl suggested I start with first commit where
> > > Khadas VIM support was added [0]. Then also Neil Armstrong suggested
> > > [1]. Then all 4.12-rc1 - rc5.
> > > Martin Blumenstingl have also found himself that: "I can reproduce the
> > > Ethernet problem (tried downloading a 1GiB test file from leaseweb,
> > > network got stuck after downloading ~70 MiB)". He suggested that I
> > > should "play with the settings on your switch (disable jumbo frames,
> > > etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
> > > connected on this same Switch port does not have any problem
> > > downloading big files or doing git clone, as well as Khadas VIM with
> > > Amlogic kernel. Also jumbo frames are not enabled, switch does have
> > > only standard settings.
> > > 
> > > I also get questioned which qdisc I use:
> > > And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
> > > $ tc -s -p qdisc
> > > qdisc noqueue 0: dev lo root refcnt 2
> > >  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> > >  backlog 0b 0p requeues 0
> > > qdisc mq 0: dev eth0 root
> > >  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
> > >  backlog 0b 0p requeues 18
> > > qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
> > > 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> > >  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
> > >  backlog 0b 0p requeues 18
> > >   maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
> > >   new_flows_len 0 old_flows_len 0
> > > $ pacman -Qi systemd
> > > Name            : systemd
> > > Version         : 232-8
> > > Description     : system and service manager
> > > Architecture    : aarch64
> > > ...
> > > $
> > > 
> > > 
> > > Regards,
> > > 
> > > > >     Andrew
> > > > 
> > > > [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372
> > > > ae310818a6292
> > > 
> > > [0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8
> > > 652da71369e
> > > [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux
> > > -amlogic/+/v4.12/integ
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
  2017-07-26 19:32                 ` Jerome Brunet
@ 2017-08-02 12:39                   ` crow
  0 siblings, 0 replies; 13+ messages in thread
From: crow @ 2017-08-02 12:39 UTC (permalink / raw)
  To: Jerome Brunet; +Cc: Andrew Lunn, netdev, open list:ARM/Amlogic Meson...

Hi Jerome,

On Wed, Jul 26, 2017 at 9:32 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Tue, 2017-07-25 at 18:56 +0200, crow wrote:
>> Hi,
>> Today I did test on ArchLinuxArm the Kernel v4.13-rc2. On downloading
>> the linux git source the network will eventually get stalled. Here are
>> the information
>>
>> Over SSH (network works).
>>
>> [root@alarm ~]# uname -a
>> Linux alarm 4.13.0-rc2-1-ARCH #1 SMP Mon Jul 24 20:02:50 MDT 2017
>> aarch64 GNU/Linux
>> [root@alarm ~]# mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-HD flow-control, link ok
>
> [Replying again on the last thread :) ]
> This 1000BaseT Half Duplex looks suspucious if the PHY is supposed to be a
> 10/100Mbps

[Resending without HTML]

I am not sure about that nor I can you answer on that. Today I used
buildroot provided by amlogic (compiled by Khadas Stuff) and there
seems no problem with the network. Here are test Report:

# uname -a
Linux buildroot 3.14.29 #1 SMP PREEMPT Tue Aug 1 15:13:51 CST 2017
aarch64 GNU/Linux

After enabling eth0 I get this information
[ 2729.827557] libphy: set driving length c
[ 2729.827667] libphy: set PLL minimum jitter
[ 2729.907553] libphy: set driving length c
[ 2729.907669] libphy: set PLL minimum jitter
[ 2731.334314] libphy: stmmac-0:08 - Link is Up - 100/Full
[ 2881.916512] tx queueing
[ 2943.916674] tx queueing
[ 3073.916713] tx queueing
[ 3083.916897] tx queueing
[ 3097.916686] tx queueing
[ 3105.916744] tx queueing
[ 3127.916700] tx queueing

(this tx queueing comes all time in Serial Console also during git
clone from linux kernel repository. After stoping traffic over ssh no
this message anymore.)


this info is before opening ssh connection to box and doing git clone.
# ethtool -S eth0
NIC statistics:
     mmc_tx_octetcount_gb: 0
     mmc_tx_framecount_gb: 0
     mmc_tx_broadcastframe_g: 0
     mmc_tx_multicastframe_g: 0
     mmc_tx_64_octets_gb: 0
     mmc_tx_65_to_127_octets_gb: 0
     mmc_tx_128_to_255_octets_gb: 0
     mmc_tx_256_to_511_octets_gb: 0
     mmc_tx_512_to_1023_octets_gb: 0
     mmc_tx_1024_to_max_octets_gb: 0
     mmc_tx_unicast_gb: 0
     mmc_tx_multicast_gb: 0
     mmc_tx_broadcast_gb: 0
     mmc_tx_underflow_error: 0
     mmc_tx_singlecol_g: 0
     mmc_tx_multicol_g: 0
     mmc_tx_deferred: 0
     mmc_tx_latecol: 0
     mmc_tx_exesscol: 0
     mmc_tx_carrier_error: 0
     mmc_tx_octetcount_g: 0
     mmc_tx_framecount_g: 0
     mmc_tx_excessdef: 0
     mmc_tx_pause_frame: 0
     mmc_tx_vlan_frame_g: 0
     mmc_rx_framecount_gb: 27
     mmc_rx_octetcount_gb: 3864
     mmc_rx_octetcount_g: 3864
     mmc_rx_broadcastframe_g: 5
     mmc_rx_multicastframe_g: 0
     mmc_rx_crc_errror: 0
     mmc_rx_align_error: 0
     mmc_rx_run_error: 0
     mmc_rx_jabber_error: 0
     mmc_rx_undersize_g: 0
     mmc_rx_oversize_g: 0
     mmc_rx_64_octets_gb: 7
     mmc_rx_65_to_127_octets_gb: 5
     mmc_rx_128_to_255_octets_gb: 12
     mmc_rx_256_to_511_octets_gb: 3
     mmc_rx_512_to_1023_octets_gb: 0
     mmc_rx_1024_to_max_octets_gb: 0
     mmc_rx_unicast_g: 22
     mmc_rx_length_error: 0
     mmc_rx_autofrangetype: 0
     mmc_rx_pause_frames: 0
     mmc_rx_fifo_overflow: 0
     mmc_rx_vlan_frames_gb: 0
     mmc_rx_watchdog_error: 0
     mmc_rx_ipc_intr_mask: 1073692671
     mmc_rx_ipc_intr: 0
     mmc_rx_ipv4_gd: 17
     mmc_rx_ipv4_hderr: 0
     mmc_rx_ipv4_nopay: 0
     mmc_rx_ipv4_frag: 0
     mmc_rx_ipv4_udsbl: 0
     mmc_rx_ipv4_gd_octets: 2816
     mmc_rx_ipv4_hderr_octets: 0
     mmc_rx_ipv4_nopay_octets: 0
     mmc_rx_ipv4_frag_octets: 0
     mmc_rx_ipv4_udsbl_octets: 0
     mmc_rx_ipv6_gd_octets: 240
     mmc_rx_ipv6_hderr_octets: 0
     mmc_rx_ipv6_nopay_octets: 0
     mmc_rx_ipv6_gd: 3
     mmc_rx_ipv6_hderr: 0
     mmc_rx_ipv6_nopay: 0
     mmc_rx_udp_gd: 15
     mmc_rx_udp_err: 0
     mmc_rx_tcp_gd: 0
     mmc_rx_tcp_err: 0
     mmc_rx_icmp_gd: 5
     mmc_rx_icmp_err: 0
     mmc_rx_udp_gd_octets: 2348
     mmc_rx_udp_err_octets: 0
     mmc_rx_tcp_gd_octets: 0
     mmc_rx_tcp_err_octets: 0
     mmc_rx_icmp_gd_octets: 248
     mmc_rx_icmp_err_octets: 0
     tx_underflow: 0
     tx_carrier: 0
     tx_losscarrier: 0
     vlan_tag: 0
     tx_deferred: 0
     tx_vlan: 0
     tx_jabber: 0
     tx_frame_flushed: 0
     tx_payload_error: 0
     tx_ip_header_error: 0
     rx_desc: 0
     sa_filter_fail: 0
     overflow_error: 0
     ipc_csum_error: 0
     rx_collision: 0
     rx_crc: 0
     dribbling_bit: 0
     rx_length: 0
     rx_mii: 0
     rx_multicast: 0
     rx_gmac_overflow: 0
     rx_watchdog: 0
     da_rx_filter_fail: 0
     sa_rx_filter_fail: 0
     rx_missed_cntr: 0
     rx_overflow_cntr: 0
     rx_vlan: 0
     tx_undeflow_irq: 0
     tx_process_stopped_irq: 0
     tx_jabber_irq: 0
     rx_overflow_irq: 0
     rx_buf_unav_irq: 0
     rx_process_stopped_irq: 0
     rx_watchdog_irq: 0
     tx_early_irq: 0
     fatal_bus_error_irq: 0
     rx_early_irq: 0
     threshold: 64
     tx_pkt_n: 31
     rx_pkt_n: 27
     normal_irq_n: 27
     rx_normal_irq_n: 27
     napi_poll: 27
     tx_normal_irq_n: 0
     tx_clean: 46
     tx_reset_ic_bit: 31
     irq_receive_pmt_irq_n: 0
     mmc_tx_irq_n: 0
     mmc_rx_irq_n: 0
     mmc_rx_csum_offload_irq_n: 0
     irq_tx_path_in_lpi_mode_n: 0
     irq_tx_path_exit_lpi_mode_n: 0
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
     phy_eee_wakeup_error_n: 0
     ip_hdr_err: 0
     ip_payload_err: 0
     ip_csum_bypassed: 0
     ipv4_pkt_rcvd: 0
     ipv6_pkt_rcvd: 0
     rx_msg_type_ext_no_ptp: 0
     rx_msg_type_sync: 0
     rx_msg_type_follow_up: 0
     rx_msg_type_delay_req: 0
     rx_msg_type_delay_resp: 0
     rx_msg_type_pdelay_req: 0
     rx_msg_type_pdelay_resp: 0
     rx_msg_type_pdelay_follow_up: 0
     ptp_frame_type: 0
     ptp_ver: 0
     timestamp_dropped: 0
     av_pkt_rcvd: 0
     av_tagged_pkt_rcvd: 0
     vlan_tag_priority_val: 0
     l3_filter_match: 0
     l4_filter_match: 0
     l3_l4_filter_no_match: 0
     irq_pcs_ane_n: 0
     irq_pcs_link_n: 0
     irq_rgmii_n: 0
# mii-tool -vvv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
  registers for MII PHY 8:
    1000 782d 0181 4400 01e1 c1e1 000f 2001
    ffff ffff ffff ffff ffff ffff ffff ffff
    0040 0082 40e8 5400 0d80 1000 0000 6400
    fff0 ffff 0000 110a 1407 0000 0e50 105a


>>   registers for MII PHY 8:
>>     1000 782d 0181 4400 01e1 c1e1 000f 2001
>>     ffff ffff ffff ffff ffff ffff ffff ffff
>>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>>     fff0 ffff 0000 000a 1407 004a 0000 105a
>>   product info: vendor 00:60:51, model 0 rev 0
>>   basic mode:   autonegotiation enabled
>>   basic status: autonegotiation complete, link ok
>>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> [root@alarm ~]# ethtool -S eth0
>> NIC statistics:
>>      mmc_tx_octetcount_gb: 0
>>      mmc_tx_framecount_gb: 0
>>      mmc_tx_broadcastframe_g: 0
>>      mmc_tx_multicastframe_g: 0
>>      mmc_tx_64_octets_gb: 0
>>      mmc_tx_65_to_127_octets_gb: 0
>>      mmc_tx_128_to_255_octets_gb: 0
>>      mmc_tx_256_to_511_octets_gb: 0
>>      mmc_tx_512_to_1023_octets_gb: 0
>>      mmc_tx_1024_to_max_octets_gb: 0
>>      mmc_tx_unicast_gb: 0
>>      mmc_tx_multicast_gb: 0
>>      mmc_tx_broadcast_gb: 0
>>      mmc_tx_underflow_error: 0
>>      mmc_tx_singlecol_g: 0
>>      mmc_tx_multicol_g: 0
>>      mmc_tx_deferred: 0
>>      mmc_tx_latecol: 0
>>      mmc_tx_exesscol: 0
>>      mmc_tx_carrier_error: 0
>>      mmc_tx_octetcount_g: 0
>>      mmc_tx_framecount_g: 0
>>      mmc_tx_excessdef: 0
>>      mmc_tx_pause_frame: 0
>>      mmc_tx_vlan_frame_g: 0
>>      mmc_rx_framecount_gb: 133
>>      mmc_rx_octetcount_gb: 16646
>>      mmc_rx_octetcount_g: 16646
>>      mmc_rx_broadcastframe_g: 9
>>      mmc_rx_multicastframe_g: 22
>>      mmc_rx_crc_error: 0
>>      mmc_rx_align_error: 0
>>      mmc_rx_run_error: 0
>>      mmc_rx_jabber_error: 0
>>      mmc_rx_undersize_g: 0
>>      mmc_rx_oversize_g: 0
>>      mmc_rx_64_octets_gb: 45
>>      mmc_rx_65_to_127_octets_gb: 64
>>      mmc_rx_128_to_255_octets_gb: 13
>>      mmc_rx_256_to_511_octets_gb: 7
>>      mmc_rx_512_to_1023_octets_gb: 4
>>      mmc_rx_1024_to_max_octets_gb: 0
>>      mmc_rx_unicast_g: 102
>>      mmc_rx_length_error: 0
>>      mmc_rx_autofrangetype: 0
>>      mmc_rx_pause_frames: 0
>>      mmc_rx_fifo_overflow: 0
>>      mmc_rx_vlan_frames_gb: 0
>>      mmc_rx_watchdog_error: 0
>>      mmc_rx_ipc_intr_mask: 1073692671
>>      mmc_rx_ipc_intr: 0
>>      mmc_rx_ipv4_gd: 117
>>      mmc_rx_ipv4_hderr: 0
>>      mmc_rx_ipv4_nopay: 0
>>      mmc_rx_ipv4_frag: 0
>>      mmc_rx_ipv4_udsbl: 0
>>      mmc_rx_ipv4_gd_octets: 12585
>>      mmc_rx_ipv4_hderr_octets: 0
>>      mmc_rx_ipv4_nopay_octets: 0
>>      mmc_rx_ipv4_frag_octets: 0
>>      mmc_rx_ipv4_udsbl_octets: 0
>>      mmc_rx_ipv6_gd_octets: 104
>>      mmc_rx_ipv6_hderr_octets: 0
>>      mmc_rx_ipv6_nopay_octets: 0
>>      mmc_rx_ipv6_gd: 1
>>      mmc_rx_ipv6_hderr: 0
>>      mmc_rx_ipv6_nopay: 0
>>      mmc_rx_udp_gd: 31
>>      mmc_rx_udp_err: 0
>>      mmc_rx_tcp_gd: 85
>>      mmc_rx_tcp_err: 0
>>      mmc_rx_icmp_gd: 2
>>      mmc_rx_icmp_err: 0
>>      mmc_rx_udp_gd_octets: 2963
>>      mmc_rx_udp_err_octets: 0
>>      mmc_rx_tcp_gd_octets: 7254
>>      mmc_rx_tcp_err_octets: 0
>>      mmc_rx_icmp_gd_octets: 92
>>      mmc_rx_icmp_err_octets: 0
>>      tx_underflow: 0
>>      tx_carrier: 0
>>      tx_losscarrier: 0
>>      vlan_tag: 0
>>      tx_deferred: 0
>>      tx_vlan: 0
>>      tx_jabber: 0
>>      tx_frame_flushed: 0
>>      tx_payload_error: 0
>>      tx_ip_header_error: 0
>>      rx_desc: 0
>>      sa_filter_fail: 0
>>      overflow_error: 0
>>      ipc_csum_error: 0
>>      rx_collision: 0
>>      rx_crc_errors: 0
>>      dribbling_bit: 0
>>      rx_length: 0
>>      rx_mii: 0
>>      rx_multicast: 0
>>      rx_gmac_overflow: 0
>>      rx_watchdog: 0
>>      da_rx_filter_fail: 0
>>      sa_rx_filter_fail: 0
>>      rx_missed_cntr: 0
>>      rx_overflow_cntr: 0
>>      rx_vlan: 0
>>      tx_undeflow_irq: 0
>>      tx_process_stopped_irq: 0
>>      tx_jabber_irq: 0
>>      rx_overflow_irq: 0
>>      rx_buf_unav_irq: 0
>>      rx_process_stopped_irq: 0
>>      rx_watchdog_irq: 0
>>      tx_early_irq: 0
>>      fatal_bus_error_irq: 0
>>      rx_early_irq: 0
>>      threshold: 1
>>      tx_pkt_n: 83
>>      rx_pkt_n: 133
>>      normal_irq_n: 130
>>      rx_normal_irq_n: 129
>>      napi_poll: 130
>>      tx_normal_irq_n: 1
>>      tx_clean: 192
>>      tx_set_ic_bit: 1
>>      irq_receive_pmt_irq_n: 0
>>      mmc_tx_irq_n: 0
>>      mmc_rx_irq_n: 0
>>      mmc_rx_csum_offload_irq_n: 0
>>      irq_tx_path_in_lpi_mode_n: 72
>>      irq_tx_path_exit_lpi_mode_n: 72
>>      irq_rx_path_in_lpi_mode_n: 0
>>      irq_rx_path_exit_lpi_mode_n: 0
>>      phy_eee_wakeup_error_n: 65535
>>      ip_hdr_err: 0
>>      ip_payload_err: 0
>>      ip_csum_bypassed: 0
>>      ipv4_pkt_rcvd: 0
>>      ipv6_pkt_rcvd: 0
>>      no_ptp_rx_msg_type_ext: 0
>>      ptp_rx_msg_type_sync: 0
>>      ptp_rx_msg_type_follow_up: 0
>>      ptp_rx_msg_type_delay_req: 0
>>      ptp_rx_msg_type_delay_resp: 0
>>      ptp_rx_msg_type_pdelay_req: 0
>>      ptp_rx_msg_type_pdelay_resp: 0
>>      ptp_rx_msg_type_pdelay_follow_up: 0
>>      ptp_rx_msg_type_announce: 0
>>      ptp_rx_msg_type_management: 0
>>      ptp_rx_msg_pkt_reserved_type: 0
>>      ptp_frame_type: 0
>>      ptp_ver: 0
>>      timestamp_dropped: 0
>>      av_pkt_rcvd: 0
>>      av_tagged_pkt_rcvd: 0
>>      vlan_tag_priority_val: 0
>>      l3_filter_match: 0
>>      l4_filter_match: 0
>>      l3_l4_filter_no_match: 0
>>      irq_pcs_ane_n: 0
>>      irq_pcs_link_n: 0
>>      irq_rgmii_n: 0
>>      mtl_tx_status_fifo_full: 0
>>      mtl_tx_fifo_not_empty: 0
>>      mmtl_fifo_ctrl: 0
>>      mtl_tx_fifo_read_ctrl_write: 0
>>      mtl_tx_fifo_read_ctrl_wait: 0
>>      mtl_tx_fifo_read_ctrl_read: 0
>>      mtl_tx_fifo_read_ctrl_idle: 0
>>      mac_tx_in_pause: 0
>>      mac_tx_frame_ctrl_xfer: 0
>>      mac_tx_frame_ctrl_idle: 0
>>      mac_tx_frame_ctrl_wait: 0
>>      mac_tx_frame_ctrl_pause: 0
>>      mac_gmii_tx_proto_engine: 0
>>      mtl_rx_fifo_fill_level_full: 0
>>      mtl_rx_fifo_fill_above_thresh: 0
>>      mtl_rx_fifo_fill_below_thresh: 0
>>      mtl_rx_fifo_fill_level_empty: 0
>>      mtl_rx_fifo_read_ctrl_flush: 0
>>      mtl_rx_fifo_read_ctrl_read_data: 0
>>      mtl_rx_fifo_read_ctrl_status: 0
>>      mtl_rx_fifo_read_ctrl_idle: 0
>>      mtl_rx_fifo_ctrl_active: 0
>>      mac_rx_frame_ctrl_fifo: 0
>>      mac_gmii_rx_proto_engine: 0
>>      tx_tso_frames: 0
>>      tx_tso_nfrags: 0
>> [root@alarm ~]#
>>
>>
>>
>>
>> [root@alarm opt]# git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> Cloning into 'linux-stable'...
>> remote: Counting objects: 6071472, done.
>> remote: Compressing objects: 100% (961861/961861), done.
>> Receiving objects:   0% (22798/6071472), 9.12 MiB | 3.47 MiB/s
>>
>>
>>
>> Over serial console:
>> journalctl -f
>> alarm systemd-timesyncd[256]: Timed out waiting for reply from
>> 144.76.197.108:123 (2.arch.pool.ntp.org).
>>
>> [root@alarm ~]# ping -c3 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>> From 10.8.8.6 icmp_seq=1 Destination Host Unreachable
>> From 10.8.8.6 icmp_seq=2 Destination Host Unreachable
>> From 10.8.8.6 icmp_seq=3 Destination Host Unreachable
>>
>> --- 8.8.8.8 ping statistics ---
>> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2047ms
>> pipe 3
>> [root@alarm ~]#
>> [root@alarm ~]# mii-tool -vvv eth0
>> Using SIOCGMIIPHY=0x8947
>> eth0: negotiated 1000baseT-HD flow-control, link ok
>>   registers for MII PHY 8:
>>     1000 782d 0181 4400 01e1 c1e1 000d 2001
>>     ffff ffff ffff ffff ffff ffff ffff ffff
>>     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>>     fff0 ffff 0000 000a 1407 0000 0000 105a
>>   product info: vendor 00:60:51, model 0 rev 0
>>   basic mode:   autonegotiation enabled
>>   basic status: autonegotiation complete, link ok
>>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> 10baseT-FD 10baseT-HD
>> [root@alarm ~]# ethtool -S eth0
>> NIC statistics:
>>      mmc_tx_octetcount_gb: 0
>>      mmc_tx_framecount_gb: 0
>>      mmc_tx_broadcastframe_g: 0
>>      mmc_tx_multicastframe_g: 0
>>      mmc_tx_64_octets_gb: 0
>>      mmc_tx_65_to_127_octets_gb: 0
>>      mmc_tx_128_to_255_octets_gb: 0
>>      mmc_tx_256_to_511_octets_gb: 0
>>      mmc_tx_512_to_1023_octets_gb: 0
>>      mmc_tx_1024_to_max_octets_gb: 0
>>      mmc_tx_unicast_gb: 0
>>      mmc_tx_multicast_gb: 0
>>      mmc_tx_broadcast_gb: 0
>>      mmc_tx_underflow_error: 0
>>      mmc_tx_singlecol_g: 0
>>      mmc_tx_multicol_g: 0
>>      mmc_tx_deferred: 0
>>      mmc_tx_latecol: 0
>>      mmc_tx_exesscol: 0
>>      mmc_tx_carrier_error: 0
>>      mmc_tx_octetcount_g: 0
>>      mmc_tx_framecount_g: 0
>>      mmc_tx_excessdef: 0
>>      mmc_tx_pause_frame: 0
>>      mmc_tx_vlan_frame_g: 0
>>      mmc_rx_framecount_gb: 14959
>>      mmc_rx_octetcount_gb: 20761536
>>      mmc_rx_octetcount_g: 20761536
>>      mmc_rx_broadcastframe_g: 22
>>      mmc_rx_multicastframe_g: 64
>>      mmc_rx_crc_error: 0
>>      mmc_rx_align_error: 0
>>      mmc_rx_run_error: 0
>>      mmc_rx_jabber_error: 0
>>      mmc_rx_undersize_g: 0
>>      mmc_rx_oversize_g: 0
>>      mmc_rx_64_octets_gb: 495
>>      mmc_rx_65_to_127_octets_gb: 658
>>      mmc_rx_128_to_255_octets_gb: 73
>>      mmc_rx_256_to_511_octets_gb: 63
>>      mmc_rx_512_to_1023_octets_gb: 124
>>      mmc_rx_1024_to_max_octets_gb: 13546
>>      mmc_rx_unicast_g: 14873
>>      mmc_rx_length_error: 0
>>      mmc_rx_autofrangetype: 0
>>      mmc_rx_pause_frames: 0
>>      mmc_rx_fifo_overflow: 0
>>      mmc_rx_vlan_frames_gb: 0
>>      mmc_rx_watchdog_error: 0
>>      mmc_rx_ipc_intr_mask: 2147385342
>>      mmc_rx_ipc_intr: 0
>>      mmc_rx_ipv4_gd: 14725
>>      mmc_rx_ipv4_hderr: 0
>>      mmc_rx_ipv4_nopay: 0
>>      mmc_rx_ipv4_frag: 0
>>      mmc_rx_ipv4_udsbl: 0
>>      mmc_rx_ipv4_gd_octets: 20476749
>>      mmc_rx_ipv4_hderr_octets: 0
>>      mmc_rx_ipv4_nopay_octets: 0
>>      mmc_rx_ipv4_frag_octets: 0
>>      mmc_rx_ipv4_udsbl_octets: 0
>>      mmc_rx_ipv6_gd_octets: 312
>>      mmc_rx_ipv6_hderr_octets: 0
>>      mmc_rx_ipv6_nopay_octets: 0
>>      mmc_rx_ipv6_gd: 3
>>      mmc_rx_ipv6_hderr: 0
>>      mmc_rx_ipv6_nopay: 0
>>      mmc_rx_udp_gd: 51
>>      mmc_rx_udp_err: 0
>>      mmc_rx_tcp_gd: 14673
>>      mmc_rx_tcp_err: 0
>>      mmc_rx_icmp_gd: 4
>>      mmc_rx_icmp_err: 0
>>      mmc_rx_udp_gd_octets: 3924
>>      mmc_rx_udp_err_octets: 0
>>      mmc_rx_tcp_gd_octets: 20178297
>>      mmc_rx_tcp_err_octets: 0
>>      mmc_rx_icmp_gd_octets: 220
>>      mmc_rx_icmp_err_octets: 0
>>      tx_underflow: 0
>>      tx_carrier: 0
>>      tx_losscarrier: 0
>>      vlan_tag: 0
>>      tx_deferred: 0
>>      tx_vlan: 0
>>      tx_jabber: 0
>>      tx_frame_flushed: 0
>>      tx_payload_error: 0
>>      tx_ip_header_error: 0
>>      rx_desc: 0
>>      sa_filter_fail: 0
>>      overflow_error: 0
>>      ipc_csum_error: 0
>>      rx_collision: 0
>>      rx_crc_errors: 0
>>      dribbling_bit: 0
>>      rx_length: 0
>>      rx_mii: 0
>>      rx_multicast: 0
>>      rx_gmac_overflow: 0
>>      rx_watchdog: 0
>>      da_rx_filter_fail: 0
>>      sa_rx_filter_fail: 0
>>      rx_missed_cntr: 0
>>      rx_overflow_cntr: 0
>>      rx_vlan: 0
>>      tx_undeflow_irq: 0
>>      tx_process_stopped_irq: 0
>>      tx_jabber_irq: 0
>>      rx_overflow_irq: 0
>>      rx_buf_unav_irq: 0
>>      rx_process_stopped_irq: 0
>>      rx_watchdog_irq: 0
>>      tx_early_irq: 0
>>      fatal_bus_error_irq: 0
>>      rx_early_irq: 6
>>      threshold: 1
>>      tx_pkt_n: 3709
>>      rx_pkt_n: 12926
>>      normal_irq_n: 4594
>>      rx_normal_irq_n: 4537
>>      napi_poll: 4597
>>      tx_normal_irq_n: 57
>>      tx_clean: 5109
>>      tx_set_ic_bit: 59
>>      irq_receive_pmt_irq_n: 0
>>      mmc_tx_irq_n: 0
>>      mmc_rx_irq_n: 0
>>      mmc_rx_csum_offload_irq_n: 0
>>      irq_tx_path_in_lpi_mode_n: 2921
>>      irq_tx_path_exit_lpi_mode_n: 2920
>>      irq_rx_path_in_lpi_mode_n: 0
>>      irq_rx_path_exit_lpi_mode_n: 0
>>      phy_eee_wakeup_error_n: 65535
>>      ip_hdr_err: 0
>>      ip_payload_err: 0
>>      ip_csum_bypassed: 0
>>      ipv4_pkt_rcvd: 0
>>      ipv6_pkt_rcvd: 0
>>      no_ptp_rx_msg_type_ext: 0
>>      ptp_rx_msg_type_sync: 0
>>      ptp_rx_msg_type_follow_up: 0
>>      ptp_rx_msg_type_delay_req: 0
>>      ptp_rx_msg_type_delay_resp: 0
>>      ptp_rx_msg_type_pdelay_req: 0
>>      ptp_rx_msg_type_pdelay_resp: 0
>>      ptp_rx_msg_type_pdelay_follow_up: 0
>>      ptp_rx_msg_type_announce: 0
>>      ptp_rx_msg_type_management: 0
>>      ptp_rx_msg_pkt_reserved_type: 0
>>      ptp_frame_type: 0
>>      ptp_ver: 0
>>      timestamp_dropped: 0
>>      av_pkt_rcvd: 0
>>      av_tagged_pkt_rcvd: 0
>>      vlan_tag_priority_val: 0
>>      l3_filter_match: 0
>>      l4_filter_match: 0
>>      l3_l4_filter_no_match: 0
>>      irq_pcs_ane_n: 0
>>      irq_pcs_link_n: 0
>>      irq_rgmii_n: 0
>>      mtl_tx_status_fifo_full: 0
>>      mtl_tx_fifo_not_empty: 0
>>      mmtl_fifo_ctrl: 0
>>      mtl_tx_fifo_read_ctrl_write: 0
>>      mtl_tx_fifo_read_ctrl_wait: 0
>>      mtl_tx_fifo_read_ctrl_read: 0
>>      mtl_tx_fifo_read_ctrl_idle: 0
>>      mac_tx_in_pause: 0
>>      mac_tx_frame_ctrl_xfer: 0
>>      mac_tx_frame_ctrl_idle: 0
>>      mac_tx_frame_ctrl_wait: 0
>>      mac_tx_frame_ctrl_pause: 0
>>      mac_gmii_tx_proto_engine: 0
>>      mtl_rx_fifo_fill_level_full: 0
>>      mtl_rx_fifo_fill_above_thresh: 0
>>      mtl_rx_fifo_fill_below_thresh: 0
>>      mtl_rx_fifo_fill_level_empty: 0
>>      mtl_rx_fifo_read_ctrl_flush: 0
>>      mtl_rx_fifo_read_ctrl_read_data: 0
>>      mtl_rx_fifo_read_ctrl_status: 0
>>      mtl_rx_fifo_read_ctrl_idle: 0
>>      mtl_rx_fifo_ctrl_active: 0
>>      mac_rx_frame_ctrl_fifo: 0
>>      mac_gmii_rx_proto_engine: 0
>>      tx_tso_frames: 0
>>      tx_tso_nfrags: 0
>> [root@alarm ~]#
>> [root@alarm ~]# ifconfig eth0 down && ifconfig eth0 up
>> Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL
>> Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>> meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
>> meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow
>> control off
>> [root@alarm ~]#
>>
>>
>>
>> whole dmesg [1]. there are some messages like: mdio-mux-mmioreg
>> c883455c.eth-phy-mux: failed to register mdio-mux bus
>> /soc/periphs@c8834000/eth-phy-mux
>>
>> [1] https://defuse.ca/b/s2NpyJlw
>>
>> Regards,
>>
>>
>> On Tue, Jun 27, 2017 at 7:14 PM, crow <crow@linux.org.ba> wrote:
>> > Hi,
>> > There are other user reporting same issue while using mainline kernel
>> > but using Ubuntu, so this is for sure not Distribution related. For me
>> > see the [0]. I hope someone would get time after 4.12 release to try
>> > fix this issue.
>> >
>> > Regards,
>> >
>> > [0] http://forum.khadas.com/t/ubuntu-server-rom-linux-mainline-v170624-pre-a
>> > lpha-version-emmc-installation/803/12
>> >
>> > On Thu, Jun 15, 2017 at 4:40 PM, crow <crow@linux.org.ba> wrote:
>> > > Hi,
>> > >
>> > > On Sun, Jun 11, 2017 at 7:03 PM, crow <crow@linux.org.ba> wrote:
>> > > > Hi Andrew,
>> > > >
>> > > > On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > > > > > Thank your for the suggestion, and thanks Martin to explaining me
>> > > > > > over
>> > > > > > IRC what actually I should do.
>> > > > > >
>> > > > > > I recompiled mainline kernel 4.12-rc4 with the Amlogic driver:
>> > > > > > replaced drivers/net/phy/meson-gxl.c with
>> > > > > > https://github.com/khadas/linux/blob/ubuntu-4.9/drivers/amlogic/ethe
>> > > > > > rnet/phy/amlogic.c
>> > > > > >
>> > > > > > But this did not solve the issue. As soon as i start git clone i
>> > > > > > lose
>> > > > > > network connection to device (no session timeout/disconnect this
>> > > > > > time,
>> > > > > > but I am unable to reconnect over SSH or to get OK ping replay
>> > > > > > back).
>> > > >
>> > > > 1) First problem reported I can't reproduce anymore, every reboot/cold
>> > > > boot with mainline kernel the Ethernet speed is detected as
>> > > > "100Mbps/Full" , but as seen in first post there was this issue.
>> > >
>> > > Once I did setup u-boot to have network in u-boot and did just an ping
>> > > to activate network. And after boot Ethernet was detected as 10Mbps.
>> > > But again was not able to reproduce it. I double check that I have 5E
>> > > cable.
>> > >
>> > > in u-boot Ethernet is detected as below
>> > > kvim#ping x.x.x.x
>> > > Speed: 100, full duplex
>> > > Using dwmac.c9410000 device
>> > > host x.x.x.x is alive
>> > > kvim#
>> > >
>> > > then I let ArchLinuxArm to boot and found out I can't connect to
>> > > device over SSH. Check over serial console and found:
>> > >
>> > > # dmesg | tail -n 10
>> > > [    8.334790] meson8b-dwmac c9410000.ethernet eth0: device MAC
>> > > address 00:15:18:01:81:31
>> > > [    8.436668] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> > > irq=-1)
>> > > [    8.535171] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
>> > > HW
>> > > [   10.225264] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>> > > wl0: Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
>> > > [   10.635703] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > 10Mbps/Half - flow control off
>> > > # uname -a
>> > > Linux khadasvimpro 4.12.0-rc4-3-ARCH #1 SMP Thu Jun 8 00:17:20 CEST
>> > > 2017 aarch64 GNU/Linux
>> > > #
>> > > # mii-tool -vvv eth0
>> > > Using SIOCGMIIPHY=0x8947
>> > > eth0: no autonegotiation,, link ok
>> > >   registers for MII PHY 8:
>> > >     1000 782d 0181 4400 01e1 0001 0005 2001
>> > >     ffff ffff ffff ffff ffff ffff ffff ffff
>> > >     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> > >     fff0 ffff 0000 000a 1407 0040 0000 105a
>> > >   product info: vendor 00:60:51, model 0 rev 0
>> > >   basic mode:   autonegotiation enabled
>> > >   basic status: autonegotiation complete, link ok
>> > >   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > >   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > #
>> > > # ifconfig eth0 down && ifconfig eth0 up
>> > > [ 1972.596690] Meson GXL Internal PHY 0.e40908ff:08: attached PHY
>> > > driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08,
>> > > irq=-1)
>> > > [ 1972.704156] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by
>> > > HW
>> > > [ 1974.795698] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > 100Mbps/Full - flow control off
>> > > #
>> > > # mii-tool -vvv eth0
>> > > Using SIOCGMIIPHY=0x8947
>> > > eth0: negotiated 1000baseT-HD flow-control, link ok
>> > >   registers for MII PHY 8:
>> > >     1000 782d 0181 4400 01e1 c1e1 000f 2001
>> > >     ffff ffff ffff ffff ffff ffff ffff ffff
>> > >     0040 0002 40e8 5400 1c1c 0000 0000 aaaa
>> > >     fff0 ffff 0000 020a 1407 00ca 0000 105a
>> > >   product info: vendor 00:60:51, model 0 rev 0
>> > >   basic mode:   autonegotiation enabled
>> > >   basic status: autonegotiation complete, link ok
>> > >   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > >   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > >   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
>> > > 10baseT-FD 10baseT-HD
>> > > #
>> > >
>> > > 2) see below
>> > > > 2) see below
>> > > >
>> > > > > So this shows it is more than a PHY problem. The Ethernet MAC driver
>> > > > > is probably also part of the problem.
>> > > >
>> > > > There are some stmmac fixes [1] in soon to be rc5, compiled current
>> > > > master (without amlogic.c) with the fixes but for me the issue still
>> > > > persist. I will compile once released rc5 with amlogic.c and report
>> > > > back.
>> > > >
>> > > > > Are there any mainline kernels which work O.K?
>> > > >
>> > > > Khadas VIM support was added in 4.12-rc1. And I did test all four rc's
>> > > > but without success.
>> > >
>> > > I did test many Kernel builds but all test have failed when
>> > > downloading bigger files / doing git clone.
>> > > As Martin Blumenstingl suggested I start with first commit where
>> > > Khadas VIM support was added [0]. Then also Neil Armstrong suggested
>> > > [1]. Then all 4.12-rc1 - rc5.
>> > > Martin Blumenstingl have also found himself that: "I can reproduce the
>> > > Ethernet problem (tried downloading a 1GiB test file from leaseweb,
>> > > network got stuck after downloading ~70 MiB)". He suggested that I
>> > > should "play with the settings on your switch (disable jumbo frames,
>> > > etc.) to rule out the "exotic" stuff?". Well other device (x86_64)
>> > > connected on this same Switch port does not have any problem
>> > > downloading big files or doing git clone, as well as Khadas VIM with
>> > > Amlogic kernel. Also jumbo frames are not enabled, switch does have
>> > > only standard settings.
>> > >
>> > > I also get questioned which qdisc I use:
>> > > And it seems I am already using fq_codel (ArchLinuxArm uses systemd):
>> > > $ tc -s -p qdisc
>> > > qdisc noqueue 0: dev lo root refcnt 2
>> > >  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> > >  backlog 0b 0p requeues 0
>> > > qdisc mq 0: dev eth0 root
>> > >  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>> > >  backlog 0b 0p requeues 18
>> > > qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum
>> > > 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>> > >  Sent 7382956 bytes 60703 pkt (dropped 0, overlimits 0 requeues 18)
>> > >  backlog 0b 0p requeues 18
>> > >   maxpacket 54 drop_overlimit 0 new_flow_count 14 ecn_mark 0
>> > >   new_flows_len 0 old_flows_len 0
>> > > $ pacman -Qi systemd
>> > > Name            : systemd
>> > > Version         : 232-8
>> > > Description     : system and service manager
>> > > Architecture    : aarch64
>> > > ...
>> > > $
>> > >
>> > >
>> > > Regards,
>> > >
>> > > > >     Andrew
>> > > >
>> > > > [1] https://github.com/torvalds/linux/commit/426849e6611f2092553f8d53372
>> > > > ae310818a6292
>> > >
>> > > [0] https://github.com/torvalds/linux/commit/e15d2774b8c096f116bf7192b37e8
>> > > 652da71369e
>> > > [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/khilman/linux
>> > > -amlogic/+/v4.12/integ
>>

Regards,

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-08-02 12:39 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-08 17:30 ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic crow
2017-06-10  7:29 ` crow
2017-06-10 15:27   ` Andrew Lunn
2017-06-11  6:31     ` crow
2017-07-26 19:27       ` Jerome Brunet
2017-06-11 13:43     ` crow
2017-06-11 15:21       ` Andrew Lunn
2017-06-11 17:03         ` crow
2017-06-15 14:40           ` crow
2017-06-27 17:14             ` crow
2017-07-25 16:56               ` crow
2017-07-26 19:32                 ` Jerome Brunet
2017-08-02 12:39                   ` 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).