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

2017-08-02 Thread crow
Hi Jerome,

On Wed, Jul 26, 2017 at 9:32 PM, Jerome Brunet  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
 

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

2017-07-26 Thread Jerome Brunet
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

2017-07-26 Thread Jerome Brunet
On Sun, 2017-06-11 at 08:31 +0200, crow wrote:
> Hi Andrew,
> 
> On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn  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 
> 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

2017-07-25 Thread crow
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

2017-06-27 Thread crow
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  wrote:
> 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

2017-06-15 Thread crow
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 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

2017-06-11 Thread crow
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.

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

2017-06-11 Thread Andrew Lunn
> 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

2017-06-11 Thread crow
Hi Andrew

On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn  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: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

2017-06-11 Thread crow
Hi Andrew,

On Sat, Jun 10, 2017 at 5:27 PM, Andrew Lunn  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 
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

2017-06-10 Thread Andrew Lunn
> 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

2017-06-10 Thread crow
Hi,

On Thu, Jun 8, 2017 at 7:30 PM, crow  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 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

2017-06-08 Thread crow
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