it seems that some of the ethernet-Patches causes this crash and that they are not needed (as i thought). I applied the patch-series (cherry-picked from 4.20-gmac_test_dsa_only) i’ve posted to mainline-kernel to 4.19…
after testing with 4.20 and now applied to (new) 4.19-gmac and tested again…seems to work without problems
here my tests (iperf over wan,lan0,wan again and lan0 again):
log
root@bpi-r2:~# uname -r
4.19.10-bpi-r2-gmac
root@bpi-r2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 9a:da:30:8e:aa:52 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 5e:06:08:25:eb:ef brd ff:ff:ff:ff:ff:ff
4: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5e:06:08:25:eb:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.0.11/24 brd 192.168.0.255 scope global wan
valid_lft forever preferred_lft forever
5: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 9a:da:30:8e:aa:52 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 9a:da:30:8e:aa:52 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 9a:da:30:8e:aa:52 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether 9a:da:30:8e:aa:52 brd ff:ff:ff:ff:ff:ff
9: wan.60@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5e:06:08:25:eb:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.60.1/24 brd 192.168.60.255 scope global wan.60
valid_lft forever preferred_lft forever
10: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 8e:c6:30:ed:4c:43 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
valid_lft forever preferred_lft forever
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.11 port 36498 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 940 Mbits/sec
root@bpi-r2:~# ip link set wan down
[ 129.232523] mt7530 mdio-bus:00 wan: Link is Down
root@bpi-r2:~# ip addr add 192.168.0.19/24 dev lan0
root@bpi-r2:~# ip link set lan0 up
[ 144.462925] mt7530 mdio-bus:00 lan0: configuring for phy/gmii link mode
root@bpi-r2:~# [ 150.717531] mt7530 mdio-bus:00 lan0: Link is Up - 1Gbps/Full - flow control off
root@bpi-r2:~#
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.19 port 38498 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
root@bpi-r2:~# ip link set lan0 down
[ 233.152510] mt7530 mdio-bus:00 lan0: Link is Down
root@bpi-r2:~#
root@bpi-r2:~#
root@bpi-r2:~#
root@bpi-r2:~# ip link set wan up
[ 289.553227] mt7530 mdio-bus:00 wan: configuring for phy/gmii link mode
root@bpi-r2:~# [ 292.717522] mt7530 mdio-bus:00 wan: Link is Up - 1Gbps/Full - flow control off
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.11 port 36502 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 940 Mbits/sec
root@bpi-r2:~# ip link set wan down
[ 318.692540] mt7530 mdio-bus:00 wan: Link is Down
root@bpi-r2:~#
root@bpi-r2:~# ip link set lan0 up
[ 352.022970] mt7530 mdio-bus:00 lan0: configuring for phy/gmii link mode
root@bpi-r2:~# [ 355.117526] mt7530 mdio-bus:00 lan0: Link is Up - 1Gbps/Full - flow control off
root@bpi-r2:~# iperf -c 192.168.0.21
------------------------------------------------------------
Client connecting to 192.168.0.21, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.19 port 38502 connected with 192.168.0.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 942 Mbits/sec
root@bpi-r2:~#
fixed crash if cpu-option is not set and want to post it to mainline, but mails got currently blocked on infradead (same as hdmi). contacted postmaster
if anybody here want to try it here is the actual patchset:
contacted andrew and florian how to get further to bring it mainline (they want to avoid dts-option and prefer bridge by user)
in my tests it lookes like this is caused by additional network-patches (qdma,bql,…). after removing them i did not seen this on 4.19 again (made multiple iperf rounds switching from gmac0 to 1 and back)…hoping phylink gets merged soon and go into next LTS. phylink works better than mainline-driver. i guess this is because of wrong gmac-setup (both need to set to same mode regardless gmac1 does not support trgmii)
Will try it but of course I will add persistent mac address for wan interface to dts file (I can’t get internet without it). As I understand it’s second gmac?
Yes, but without luck. It’s still lost network ports randomly (can see crash in dmesg if its yet restores network but it’s not always) and this make me crazy. Have tried 4.14 - no errors but very poor pptp vpn and I need these two (network and pptp) work. So just put device on the shelf and wait till someone release stable kernel
We need a way to reproduce the error if it also happens with 5.3-phylink-x. So try thos version and look if you get the error again…then thunk about what you/system have done while the error comes up and try this again
Tried to give another try for this device and what I did - used latest stable ubuntu 19.04 and compiled kernel from it (before was compiled kernel from debian 9 and default gcc) with gcc 8.x - no error reproduced. Then installed GCC 9.x and tried - no driver erros for two days uptime (before was 3-5 times per day). Still watching for it.
Linux version 4.19.69-bpi-r2-main (shashilx@ubuntu) (gcc version 9.1.0 (Ubuntu 9.1.0-2ubuntu2~19.04)) #2 SMP Fri Sep 6 11:45:53 EEST 2019
i think yes it doesn’t matter in which system but I think it’s matter wich compiler version. don’t know if it’s gcc version or newer kernel version (hangs was in .66 and it’s .69)
