H2/H3: "old problem" Link (eth0) is Up/Down syndrom

[guidol]

Armbianmonitor:

http://ix.io/232T

on a Sunvell R69 (H2) and a NanoPi Neo (H3) I got these "old known" eth0 Link Up/Down syndrom, but couldnt find a solution in the forum while using the search-engine

 

armbianmonitor -u
System diagnosis information will now be uploaded to

Sunvell R69 - Linux sunvell-r69 5.4.0-rc8-sunxi #19.11.3 SMP Wed Nov 27 17:01:29 CET 2019 armv7l armv7l armv7l GNU/Linux : 

http://ix.io/232T

 

NanoPi Neo - Linux npi-neo 5.3.3-sunxi #5.98 SMP Sat Oct 5 18:34:15 +03 2019 armv7l GNU/Linux :

http://ix.io/232U

in dmesg it looks like
 

[10536.264427] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10568.008879] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[10571.081067] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10575.177000] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[10580.297247] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10604.873552] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[10607.945753] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10608.969632] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[10612.041827] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10631.498029] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[10633.546213] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[10636.618141] dwmac-sun8i 1c30000.ethernet eth0: Link is Down

I have the feeling its could have to do with using 1GBit/1000MBit devices on the same 100MBit-Ethernet-Hub, because I do get much mor of these messages when my armbian-build-system-PC is on (which uses a onboard GBit-Ethernet-Card).
On the 100MBit-Hub there are also some othe 1GBit-Devices like the NanoPi Neo2.

On the PC I did try to force the 1GBit-Card to 100MBit with ethtool -s eth0 speed 100 autoneg off 

But that doesnt seem to help.

 

On other SBC-devices I could find these messages in the dmesg (and in the froum search it was a problem 4 to 2 years ago)

 

On the other hand there was a disscussion about a new driver version for kernel 4.1.4 at
https://forum.armbian.com/topic/4364-dwmac-sun8i- driver-v6/

 

 

With debian stretch armabian 5.41 and kernel 4.1.4.34 I did see that problem (and doenst feel it at a SSH-session) on the Sunvell R69. 

[guidol]

Also with kernel 5.4.1 on the OrangePi R1 (H2+ CPU)
Changed Network-cable, Power-supply, dcard which do work without problems on other SBCs

SSH-session is mostly unuseable
I also deinstalled network-manager and do only use /etc/network/interfaces.

Maybe I will check tomorrow if connection via WiFi is more "stable"!?

 

BTW: I did also read about some SBCs other than H2/H3 who have Network/SSH-problems since kernel 5.3/5.4.y,

but they did show the error-message in the dmesg.

Armbian Buster with Linux 5.4.1-sunxi
package bsp-kernel[19.11.3.339] u-boot[19.11.3] dtb[19.11.3.339] 
firmware[19.11.3.334] config[19.11.3.334] branch[dev]

[   33.781329] vcc3v0: disabling
[   33.781350] vcc5v0: disabling
[   59.349570] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   67.541687] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   74.709525] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   92.117671] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  113.621488] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  115.669653] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  152.533554] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  154.581720] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  169.941894] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  171.990061] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  181.206113] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  184.278327] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  188.374256] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  191.446457] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  193.494356] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  195.542543] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  219.094889] dwmac-sun8i 1c30000.ethernet eth0: Link is Down

 

[Igor]

What is the u-boot version?

[guidol]

10 hours ago, Igor said:

What is the u-boot version?

@Igor its for the OPi R1

U-Boot SPL 2019.10-armbian (Dec 05 2019 - 19:02:23 +0300)

dpkg -l|grep u-boot
linux-u-boot-orangepi-r1-dev 19.11.3   armhf  Uboot loader 2019.10

 

I also compiled a legacy image, but here I did also get Uboot 2019.10:

linux-u-boot-legacy-orangepi-r1_19.11.3_armhf.deb
U-Boot SPL 2019.10-armbian (Dec 06 2019 - 08:52:44 +0300)
dpkg -l|grep u-boot
linux-u-boot-orangepi-r1-legacy 19.11.3 armhf Uboot loader 2019.10

with the same problems:
 

Spoiler

[  225.629410] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  226.653640] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  231.773488] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  232.797650] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  233.373175] ==> rtl8188e_iol_efuse_patch
[  235.869420] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  243.037541] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  247.133489] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  248.157639] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  250.205402] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  254.301629] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  258.397501] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  264.541706] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  268.637493] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  271.709631] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  275.805495] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  277.853624] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  281.949493] dwmac-sun8i 1c30000.ethernet eth0: Link is Down

 

but also often:
 

[   76.501287] ==> rtl8188e_iol_efuse_patch
[   81.373252] ==> rtl8188e_iol_efuse_patch
[  104.449252] ==> rtl8188e_iol_efuse_patch
[  137.369173] ==> rtl8188e_iol_efuse_patch
[  180.377180] ==> rtl8188e_iol_efuse_patch
[  233.373175] ==> rtl8188e_iol_efuse_patch
[  296.433174] ==> rtl8188e_iol_efuse_patch
[  359.465161] ==> rtl8188e_iol_efuse_patch
[  422.466610] ==> rtl8188e_iol_efuse_patch
[  485.403544] ==> rtl8188e_iol_efuse_patch
[  548.408481] ==> rtl8188e_iol_efuse_patch

 

[guidol]

@Igor interesting side-effect-information: its seems that only the onboard eth0 dwmac-sun8i 1c30000.ethernet

is affected by the down/up-link syndrom

 

if I do use the second ethernetport of the OPi R1 (which is connected onboard via USB) then I dont have this

down/up-link syndrom:
 

enxc0742bffe8ff
[    2.815218] usbcore: registered new interface driver usb-storage
[    3.471264] usb 3-1: New USB device found, idVendor=0bda, idProduct=8152, bcdDevice=20.00
[    6.781528] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator
[    7.062463] usbcore: registered new interface driver r8152
[    7.429322] r8152 3-1:1.0 eth2: v1.10.10
[    7.611054] r8152 3-1:1.0 enxc0742bffe8ff: renamed from eth2

Also a external USB-Ethernet device isnt affected by the down/up-link syndrom:

enx00123455562b
[    7.107788] MOSCHIP usb-ethernet driver 4-1:1.0 eth1: register 'MOSCHIP usb-ethernet driver' at usb-1c1c000.usb-1, MOSCHIP 7830/7832/7730 usb-NET adapter, 00:12:34:55:56:2b
[    7.108080] usbcore: registered new interface driver MOSCHIP usb-ethernet driver
[    7.568243] MOSCHIP usb-ethernet driver 4-1:1.0 enx00123455562b: renamed from eth1

All 3 were connected to the same ethernet-cable running with the same OS, Power-Supply and SDCard.

[guidol]

maybe its the RTL8211E PHY which is used for eth0?

 

https://linux-sunxi.org/Ethernet

Quote

The SoC's GMAC is always combined with an external PHY, in most cases a RTL8211E/CL (the Lamobo R1 uses the Broadcom BCM53125 switch IC instead). Important: In this special mode the RTL8211 chip is just used as PHY and only responsible for layer 1 operations, since everything else happens inside the SoC's GMAC (therefore no RealTek drivers are needed and some functionality differs, e.g. no WoL possible).

 For reliable Gigabit networking (1000Mbit operation), several sunxi devices require an important tweak that adjusts the relative timing of the clock and data signals to the PHY, in order to compensate for differing trace lengths on the PCB (details). Among others, this includes Banana Pi/Pro, Cubietruck, Lamobo R1, pcDuino3 Nano and Orange Pi/Mini. Recent mainline U-Boot uses CONFIG_GMAC_TX_DELAY to initialize these devices accordingly. If a necessary GMAC TX delay isn't set, then GBit Ethernet operation might be unreliable or won't work at all. 10/100 Mbit/sec negotiation is unaffected, so misconfigured devices could actually work (faster) when connected to a Fast Ethernet port instead of a GBit Ethernet port.

 

see also
https://forum.pine64.org/showthread.php?tid=5712
https://patchwork.ozlabs.org/patch/873752/
https://lkml.org/lkml/2017/8/22/9

 

and maybe here?
https://lore.kernel.org/lkml/20170908142825.GC3037@Red/t/

[Igor]

Yes, it looks like somebody played with timings or we miss some patch adjusting this ... since we are changing release model, master will only be build ready, other things will be more fragile https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md (WIP) users should stick to released branches. They should not have this problem since u-boot is old there ... 

[guidol]

1 hour ago, Igor said:

Yes, it looks like somebody played with timings or we miss some patch adjusting this ... since we are changing release model, master will only be build ready, other things will be more fragile https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md (WIP) users should stick to released branches. They should not have this problem since u-boot is old there ... 

my ./userpatches/config-default.conf defaults to branch master as LIB_TAG

but I cant set BRANCH=master at compile.sh because then I do get

[ error ] Kernel branch not defined for this board [ master ]
 

So I could use LEGACY, CURRENT and DEV and maybe NEXT

Which branch should I use to get an older u-boot?

I think released branches are v19.08 and v19.11  (took the names from https://github.com/armbian/build )

but I also do get

[ error ] Kernel branch not defined for this board [ v19.08 ]
[ error ] Kernel branch not defined for this board [ v19.11 ]

 

But also with LEGACY and NEXT I do get only the new u-boot 2019.10

Please give me a info what to try

 

[Igor]

On 12/6/2019 at 11:15 PM, guidol said:

Please give me a info what to try

Your build directory is probably not clean and it does not change properly. Hmm ... but there are older binaries in the https://apt.armbian.com/pool/main/l/ 

 

Install them + armbian-config -> system -> update boot loader (+ de-install older before)

[guidol]

3 hours ago, Igor said:

Your build directory is probably not clean and it does not change properly. Hmm ... but there are older binaries in the https://apt.armbian.com/pool/main/l/ 

Install them + armbian-config -> system -> update boot loader (+ de-install older before)

First I did try to compile with CLEAN_LEVEL="make,debs,oldcache,cache,alldebs" - that cleaned many files/dirctorys, but also did try to compile u-boot 2019.10 instead of 2019.04

 

Now I deleted my ./build-dirctory and cloned (again) the armbian-build - hope thats clean enough

 

I did also try to install bootloader via armbian-config

On the OPi R1 I did get:

linux-u-boot-orangepi-r1-dev  19.11.3  armhf  Uboot loader 2019.04

 

With this u-boot eth0 is (also) found - but cant be used

 

dmesg seems to be OK:

[    2.718770] libphy: Fixed MDIO Bus: probed
[    2.719328] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy not found, using dummy regulator
[    2.719403] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
[    2.719893] libphy: stmmac: probed
[    2.720380] dwmac-sun8i 1c30000.ethernet: Found internal PHY node
[    2.720477] libphy: mdio_mux: probed
[    2.720494] dwmac-sun8i 1c30000.ethernet: Switch mux to internal PHY
[    2.720502] dwmac-sun8i 1c30000.ethernet: Powering internal PHY
[    2.731395] libphy: mdio_mux: probed
[    3.134611] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[    8.052169] dwmac-sun8i 1c30000.ethernet eth0: PHY [0.1:01] driver [Generic PHY]
[    8.053364] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found
[    8.053380] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[    8.053390] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[    8.053403] dwmac-sun8i 1c30000.ethernet eth0: configuring for phy/mii link mode

eth0 is blinking like a heartbeat with the yellow/green led at the same time

 

second onboard-ethernet-port via usb is working.

 

[guidol]

with fresh git--cloned armbian-build-system compiled:

Armbian Buster with Linux 5.4.2-sunxi

package bsp-kernel[19.11.3] u-boot[19.11.3] dtb[19.11.3] firmware[19.11.3] config[19.11.3]
branch[dev]
 

linux-u-boot-orangepi-r1-dev  19.11.3  armhf  Uboot loader 2019.10

linux-dtb-dev-sunxi           19.11.3  armhf  Linux DTB, version 5.4.2-sunxi
linux-image-dev-sunxi         19.11.3  armhf  Linux kernel, version 5.4.2-sunxi

 

eth0 doenst work- but usb-ethernet

CURRENT image only has the "patched/buggy" 5.3 kernel

 

 

[guidol]

35 minutes ago, guidol said:

eth0 doenst work- but usb-ethernet

strange - eth0 is working (with down/up-link-syndrom) when powered via MicroUSB with org. Raspberry Pi power-supply, but not via the power-barrel-connector which is installed on my OPi R1.

Spoiler

[   33.781379] vcc3v0: disabling
[   33.781398] vcc5v0: disabling
[   36.213802] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   63.860722] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   66.932859] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   70.004716] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   74.100856] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   78.196731] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   80.244862] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   83.316714] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   85.364855] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   93.556750] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[   96.628785] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  113.018029] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  116.090292] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  132.474376] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  135.546821] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  145.786562] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  151.930964] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  160.122733] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  163.195196] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  165.242813] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  168.315266] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  174.458935] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  177.531355] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  185.723009] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  187.771176] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  194.939061] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  198.011499] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  222.587242] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  224.635439] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  287.099024] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  289.147172] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  309.627008] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  312.699461] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  330.107200] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  332.155394] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[  352.635420] dwmac-sun8i 1c30000.ethernet eth0: Link is Down
[  356.731601] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

This barrel-connector has now worked since 2 years and now it seems to get not enough power to the board for the normal eth0, bt for the usb-eth1?

 

 

[Igor]

10 hours ago, guidol said:

strange - eth0 is working (with down/up-link-syndrom) when powered via MicroUSB with org. Raspberry Pi power-supply, but not via the power-barrel-connector which is installed on my OPi R1.

Probably there is a bug in the board DT or withing u-boot. Close inspection and comparing to reality is needed.

[Dulfaen]

I have the same problem on an OrangePi One (H3) with Armbian_20.02.0-rc0_Orangepione_bionic_current_5.4.12. I changed the board, the SD-card and the patch cord, but not the power-supply. I also tried the last archived legacy Image for the OrangePi One. I always got the same problem. I fiddled around with ethtool and found that turning off the auto-negotiation for the ethernet-connection fixed it for me. I don't know whats going on in the background. As I understand it,  depending on the other side of the connection the connection could end as 10 Mbps half duplex if the auto-negotiation is turned off. But in my case (Fritzbox) the connection is rock-solid and the speed is also good. So maybe this solution that i found in some forum helps you too:

Spoiler

 

### testing ###############################

ethtool -s eth0 autoneg off speed 100 duplex full

 

### permanent (with NetworkManager) #########

#create new file

nano /etc/NetworkManager/dispatcher.d/50-ethtool-autoneg-off

 

#content

#!/bin/sh
myname=${0##*/}
log() { logger -p user.info -t "${myname}[$$]" "$*"; }
IFACE=$1
ACTION=$2

case ${IFACE} in
    eth0)
        case ${ACTION} in
            up)
                log "Disabling auto-negotation on $IFACE"
                ethtool -s $IFACE autoneg off speed 100 duplex full
                ;;
        esac
        ;;
esac

 

#permissions

chmod 0744 /etc/NetworkManager/dispatcher.d/50-ethtool-autoneg-off

 

 

### permanent (with ifup) ####################

#adjust Networkmanager config

nano /etc/NetworkManager/NetworkManager.conf

#adjust

[ifupdown]
managed=false

 

#adjust interfaces

nano /etc/network/interfaces

#add (adjust ip's and masks)

allow-auto eth0
allow-hotplug eth0

iface eth0 inet static
    address 192.168.0.5
    netmask 255.255.255.0
    gateway 192.168.0.1
    broadcast 192.168.0.255 
    dns-nameservers 192.168.0.1 8.8.8.8
    up /sbin/ethtool -s eth0 autoneg off speed 100 duplex full
  
iface eth0 inet6 auto

 

Edited January 26, 2020 by Dulfaen
added ifup version

[Alexey Bogomolov]

So what should I do with this problem? This problem has been present for at least four years, on all kernels, on any armbian build. When will the solution appear?

All tricks with ethtool doesen't work!

[Werner]

50 minutes ago, Alexey Bogomolov said:

When will the solution appear?

Being rude does not solve issues faster. However there ARE ways to accomplish this. Please consider studying the "Support" section here: https://github.com/armbian/build#support

[guidol]

On 11/28/2019 at 5:38 PM, guidol said:

 

I have the feeling its could have to do with using 1GBit/1000MBit devices on the same 100MBit-Ethernet-Hub, because I do get much more of these messages when my armbian-build-system-PC is on (which uses a onboard GBit-Ethernet-Card).
On the 100MBit-Hub there are also some other 1GBit-Devices like the NanoPi Neo2.

 

@Igor and who also have an interest in this issue/topic

After a long time - today Ethnernet is since hours stable again on my NanoPi Neo (no Network/eth0 down/up)
BUT I didnt changed the software (armbian)

Yesterday my NanoPi Neo had down/up (also) with Kernel 5.11.2-dev and debian buster and now today its stable since hours!

 

What I did? No it wasnt the software, nor the ethernet-cable, nor the Power-Supply, nor the eth0-setting.

I have a 16-port-Ethnernet-Hub with 100MBit, but its optical devided in 2x(2x4):

1st   2nd
2x4 + 2x4  = 16 ports 
####  ####
####  ####

 

The nanoPi Neo was in the 2nd 2x4 ports with the problem and after putting him in the 1st 2x4 port section the NanoPi Neo port did go stable.

 

In the 1st 2x4 ports are more or mostly (or only?) 100MBit devices and in the 2nd 2x4 are some/more 1GBit-devices.

 

I - personally - think the NanoPi Neo Ethernet-PHY didnt/doesnt tolerate some sort of ethernet-phy at the 2nd 2x4 port-part.

At the 1st 2x4port-part it seems he found ethernet-phys he could tolerate.

This is for today my "absurd" theory  - BECAUSE it does work now for hours without a single up/down message in dmesg

[Adrian Cable]

We have a commercial product running on Armbian based on the OPi Zero platform. We occasionally get reports from customers of intermittent connectivity, which (looking at the dmesg log on affected devices) manifests itself as something that looks very much like the up/down syndrome reported here. In this case we advise customers to purchase a cheap switch (e.g. https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unmanaged/dp/B07S98YLHM/ref=sr_1_3?dchild=1&keywords=4+port+switch&qid=1614793487&sr=8-3) and put it between our product and their existing switch or router. We have found this always resolves the issue.

 

We still don't understand the cause, but at least we have a workaround (albeit not a perfect one).

[guidol]

@Igor just one more "repaired" patient
After getting at Tuesday the NanoPi Neo working fine with his eth0 - I did gave my Orange Pi R1 a new "ride" today.

 

The last months (or year) I did think his eth0 is defective, because when ethernet there is inserted the orange-led blinks only on/off and isnt accessable when the Orange Pi R1 is booted. I could only use the second ethernet port (WITH THE SAME cable) which is onboard conected via USB (enx-device)

 

Today I put him on the same 1st 2x4 ports of my 16 port 100MBit Hub - and the blinking orange led stays on and does work as eth0

 

System diagnosis information has been uploaded to http://ix.io/2RUJ

 

Because I have no more feee ports I had to move another system from the 1st to the 2nd part of the Ethernet-Switch.

 

So also the Orange Pi R1 - like the NanoPi Neo - seems to have a difference on their eth0-port (phy?)  against other systems.

Strange for me was that the 2nd onboard-USB-connected Ethernet-port did work on the same Ethernet-cable (and Switch-Port), but not on the onboard chipset-included eth0.

 

So in the past we took that as some "Voodoo" and many other people with other Ethernet-Switches.

The "solution" of @Adrian Cable should be tested in future by such network problems

[arxstax]

I had same problem on OPi PC+ using the latest:  Armbian_21.05.1_Orangepipcplus_focal_current_5.10.34

 

I managed to get it to stay up (has been over 12 hrs so far) by doing the following.  Perhaps this is a clue on what might be happening. 

 

1. Blacklisted wifi since I don't use it.  Not sure if this is part of the problem or not.  I added these lines to /etc/modprobe.d/blacklist.conf

 

blacklist 8189fs
blacklist r8723bs

 

2.  Use nmtui to set mac address and static IPv4 address.

 

Problem gone.

 

 

 

 

 

[lanefu]

interesting yeah started gettin some NIC stuff on my pineh64 recently after I moved up my kernel.. haven't tried disabling wifi drive..  kept on thinking it was the clock rolling backwards. need to do more testing.. will look into module blacklikst tho

[arxstax]

I am going to try putting back wifi but keep the static v4 address stuff.  Could help steer in the right direction.  I do recall that blacklisting wifi alone did not fix the dropping.

 

 

[arxstax]

Been up for over an hour with wifi modules in place.  Wifi not connected though.  Would never stay up this long before.

 

So it has something to do with static vs dynamic address (either MAC and/or IPv4). 

 

Knowing this, is there a particular log that I can take of the problem to help out?

[lanefu]

hmmmmmmm

https://askubuntu.com/questions/1288683/dhclient-doesnt-renew-lease-when-ntp-syncs-the-time-backwards

/var/log/syslog and /var/log/kernel and /var/log/dmesg

[lanefu]

On 6/21/2021 at 11:55 AM, arxstax said:

So it has something to do with static vs dynamic address (either MAC and/or IPv4). 

Yep! DHCP renewal seems to freak out chrony and caused the system clock to rollback....  Been stable since I switched to static IP.. now to find a real fix....

[lanefu]

spoke with @Igor and issue may be related to u-boot.... will investigate more.. just making note here

[Adrian Cable]

On 7/10/2021 at 7:32 AM, lanefu said:

spoke with @Igor and issue may be related to u-boot.... will investigate more.. just making note here

 

This sounds very interesting. Care to share some more? Thank you!

[lanefu]

I donr have the why but  downgrading the uboot package to an older one from our deb archive does seem to solve.

[Adrian Cable]

On 7/24/2021 at 4:51 AM, lanefu said:

I donr have the why but  downgrading the uboot package to an older one from our deb archive does seem to solve.

 

Any more details so this is actionable by the community? Version/commit numbers of u-boot for working vs. non-working would be a great start on the way to a git bisect.

[Igor]

On 3/3/2021 at 6:46 PM, Adrian Cable said:

We have a commercial product running on Armbian based on the OPi Zero platform.

 

2 hours ago, Adrian Cable said:

Any more details so this is actionable by the community? Version/commit numbers of u-boot for working vs. non-working would be a great start on the way to a git bisect.

 

Put few thousands on our account if you have such ideas or hire someone to get you that information. We have shared all we know - we always do that. To get a better information, to find a bug, additional time has to be lost. Perhaps a day is enough, perhaps a week wont. And we have other, much more important things to do. We would improve this service ... 

Edited July 28, 2021 by Igor
removed "but you don't care"