Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi Jerome, On Wed, Jul 26, 2017 at 9:32 PM, Jerome Brunetwrote: > 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
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 > > 0040 0002 40e8 5400 1c1c > fff0 000a 1407 004a 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
On Sun, 2017-06-11 at 08:31 +0200, crow wrote: > Hi Andrew, > > On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunnwrote: > > > 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 > author: Baoqi wang > description:Amlogic Meson GXL Internal PHY driver > alias: mdio:0001100101000100 > 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 > > 0040 0002 40e8 5400 1c1c > fff0 040a 1407 004a 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 > > 0040 0002 40e8 5400 1c1c > fff0 040a 1407 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 c941.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 c941.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 c941.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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
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 0040 0002 40e8 5400 1c1c fff0 000a 1407 004a 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
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, crowwrote: > Hi, > > On Sun, Jun 11, 2017 at 7:03 PM, crow wrote: >> Hi Andrew, >> >> On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn 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.c941 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 c941.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 c941.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 c941.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 > > 0040 0002 40e8 5400 1c1c > fff0 000a 1407 0040 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 c941.ethernet eth0: PTP not supported by HW > [ 1974.795698] meson8b-dwmac c941.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 > > 0040 0002 40e8 5400 1c1c > fff0 020a 1407 00ca 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi, On Sun, Jun 11, 2017 at 7:03 PM, crowwrote: > Hi Andrew, > > On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunn 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.c941 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 c941.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 c941.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 c941.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 0040 0002 40e8 5400 1c1c fff0 000a 1407 0040 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 c941.ethernet eth0: PTP not supported by HW [ 1974.795698] meson8b-dwmac c941.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 0040 0002 40e8 5400 1c1c fff0 020a 1407 00ca 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi Andrew, On Sun, Jun 11, 2017 at 5:21 PM, Andrew Lunnwrote: >> 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
> 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi Andrew On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunnwrote: >> 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:0001100101000100 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 0040 0082 40e8 5400 0d80 1000 a900 fff0 130a 1407 00ca 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 0040 0082 40e8 5400 0d80 1000 a900 fff0 130a 1407 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 c941.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 c941.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 c941.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 c941.ethernet eth0: Link is Up - 100Mbps/Full - flow control off then I took eth0 and wlan0 up (same ArchLinuxArm
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi Andrew, On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunnwrote: >> 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 author: Baoqi wang description:Amlogic Meson GXL Internal PHY driver alias: mdio:0001100101000100 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 0040 0002 40e8 5400 1c1c fff0 040a 1407 004a 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 0040 0002 40e8 5400 1c1c fff0 040a 1407 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 c941.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 c941.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 c941.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 c941.ethernet eth0: PTP not supported by HW [Sun Jun 11 07:54:30 2017] meson8b-dwmac c941.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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
> 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
Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
Hi, On Thu, Jun 8, 2017 at 7:30 PM, crowwrote: > 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 c941.ethernet eth0: Link is Up - 10Mbps/Half - flow > control off > > Works (if I do ifconfig eth0 down / up): > meson8b-dwmac c941.ethernet eth0: Link is Down > meson8b-dwmac c941.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: 0x003f (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 0040 0082 40e8 5400 0d80 1000 a900 fff0 140a 1407 00ca 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 0040 00c2 40e8 5400 0803 0009 fff0 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
ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
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 c941.ethernet eth0: Link is Up - 10Mbps/Half - flow control off Works (if I do ifconfig eth0 down / up): meson8b-dwmac c941.ethernet eth0: Link is Down meson8b-dwmac c941.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: 0x003f (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