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

[Adrian Cable]

14 minutes ago, Igor said:

 

 

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, but you don't care so ... 

 

@Igor - I have just put a few thousands on your account. Can I therefore kindly a request a withdrawal of the "you don't care" part of the above? Thank you.

[Igor]

20 minutes ago, Adrian Cable said:

Thank you.

Likewise! 

[Adrian Cable]

2 minutes ago, Igor said:

Likewise! 

 

You are (very genuinely) welcome!

[lpirl]

For those who end up here via search engines:

 

On a NanoPI M4V2 (RK3399) I activated the `tuned` profile "latency-performance" for my use case without the intention to address this issue. Thus, by coincidence, I recognized that the issue apparently disappeared (or got a lot less frequent, at least, since it hasn't appeared in the last 12 hours). I don't have the time/priority to track down which of the settings actually helped but it should be the governor or cstate settings.

[geckow]

Thank you @lpirlfor your tip, unfortunately it did not work on my Orange Pi PC (H3 CPU), running Armbian 22.05.1 Bullseye with Linux 5.15.43-sunxi.

Here is what I tried (as root) :

apt install tuned tuned-utils tuned-utils-systemtap
tuned-adm profile latency-performance
reboot

 

It happens since I changed my ISP (and the router they provide). I tried all ethernet ports, but unfortunately nothing worked

@guidolwas right, I will try to put a switch between the router and the OPi to see if it gets better!

[serg_stetsuk]

Hi All.

 

I have nanopi-neo with exactly the same problem.

What I've found is that link may be established if i turn off autonegotiation on my PC and force 10Half mode.

However it is still not fully functional. I can seed Rx packets are growing as well as Tx packets. But there are no packets actually transmitted (checked with wireshark on PC).

 

I can experiment. Can anyone suggest what should I try to troubleshoot?

[kbhuinfo]

On an orange pi one I notice the same regularly:

 

│Jan 21 15:50:25 a-m kernel: [ 1757.658898] dwmac-sun8i 1c30000.ethernet eth0: Link is Down                                                                                                         │
│Jan 21 15:50:27 a-m NetworkManager[1119]: <info>  [1674312627.1444] device (eth0): carrier: link connected
  ...

 

I can test with multiple samples.

[Dav]

Hi there.

I have a Pine A64(+) board (https://pine64.org/documentation/Pine_A64/)

I have been experiencing this issue since last year. I updated the SO (armbian version + kernel) several times and it didn't resolve the issue.
It happens randomly. The CPU and storage are not overheated (30º C each) and I tested all physical components (board, ethernet wire, switch, ...)

ambianmonitor -u -> https://paste.armbian.com/arozepuxen

 

Things I tested for now:
- Daily reboot. Sometimes eth0 is not wake up after boot and I have to physically power-toggle the board.

- Stay on latest raspbian release (24.2.1) + latest kernel (6.6.16) + latest uboot. Same issue.

- Stay on latest raspbian release (24.2.1) + legacy kernel (6.1.77) + latest uboot. Same issue.

- Armbian 23.11.1 Jammy with Linux 6.1.63-current-sunxi64 was also some time the SO in the board. Same issue.

- Also I set the segmentation and MTU as here but same issue:

 

Notes:

- CPU is "on demand". That's also why the temperature is OK.

- Somehow is only 100Mbits available (the board has gigabit port). By the way, is not my concerning now.

- https://github.com/jwrdegoede/rtl8189ES_linux/tree/rtl8189fs I saw this driver. Is this an option? Should I try?

Any idea? Should I totally rebuild the microsd SO from zero with an ARMBIAN from 2021 or so?
Any other suggestion? The board is totally unstable as it currently is and I guess is software related (driver maybe)

Thank you.
 

[Dav]

Update:

I "fixed it" with https://mmonit.com/wiki/Monit/Installationmonit

 

Basically, each 60 seconds it will check if my "eth0" ethernet interface is up. If not, it tries to wake it up.

If for some reason, the port/board cannot wake up the ethernet interface... I have a secondary check (ping Google DNS IP 10 times in a row -> one per minute). If 10/10 failed, it reboots the board.

 

Is not ideal, but now I have a "hands free" board. This is in a countryside, so before this "patch", I had to take my car to manually power-cycle the board hahaha

Here you have, the config I used:

 

Quote

/etc/monit/monitrc

## Start Monit in the background (run as a daemon):
#
set daemon  60             # check services at 60 seconds intervals
   with start delay 120    # optional: delay the first check by 2-minutes (by
#                           # default Monit check immediately after Monit start)
#
set log /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state
 set eventqueue
     basedir /var/lib/monit/events  # set the base directory where events will be stored
     slots 100                      # optionally limit the queue size

###############################################################################
## Services
###############################################################################
##
check network eth0 with interface eth0
  start program = "/sbin/ifconfig eth0 up"
  stop program = "/sbin/ifconfig eth0 down"
  if link down then restart

check host 8.8.8.8 with address 8.8.8.8
  if failed ping count 10 size 128 with timeout 10 seconds then exec "/usr/sbin/reboot"

 

 

 I hope this can be helpful to somebody.

 

Regards

Edited June 3 by Dav

[Dancer]

Hi! I had the same problem on OrangePI PC Plus. 

I have tried different images, settings, and power supply but nothing helps.

 

Then I checked my router Netis(N1) and  I found my OrangePI in DHCP clients with another IP. Not static IP that I set manually. Maybe It was IP conflict between the static IP I set on the device and the DHCP IP router had in memory.

I reserved IP on the router directly for the specific OrangePI Mac address. After this ethernet works stable for the 16 hours.