Armbian 24.2.1 Linux 6.6.16-current-sunxi - deadloop after network link got lost

[klaute]

Hello,

 

I‘m recently updated to Armbian 24.2.1 Bookworm with Linux 6.6.16-current-sunxi.

 

The system is running fine but if I disconnect the network interface, the system gets stuck in kind of a dead loop.
This behavior gave me the hint that my WiFi repeater is broken and needs to be exchanged. Anyway, the CPU temperature rises and no further interaction with the system is possible.

 

If I disconnect it, from a normal operating switch, the OpiOne’s behavior looks the same.

 

My problem with this behavior is that after reconnecting the network, it does not get back available, until I do a power cycle.

 

I tried to read out the root of that problem out of the logs but didn’t had success yet.

I have uploaded the monitor logs:

https://paste.armbian.com/cuqayiyimi
 

Further information: A cooler is attached to the CPU and my PSU is able to provide 6A current.

I haven’t had a problem with this Orange Pi during the last 4 years of running an older outdated version of Armbian.

I’m only running some docker container with only use minimum resources.

 

I hope that this isn’t a duplicate, haven’t found other topics like that.

 

best regards

kai

 

[Stephen Graf]

@klaute I did a quick check with my test orangepione and could not replicate your problem. I tested with 100Mbs and 1Gbps Ethernet switches.

 

Welcome to Armbian 24.2.1 Bookworm with Linux 6.6.16-current-sunxi

 

root@orangepione:~# ip addr
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
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0
       valid_lft forever preferred_lft forever
    inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
root@orangepione:~# ip addr
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
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0
       valid_lft forever preferred_lft forever
    inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
root@orangepione:~# ip addr
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
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0
       valid_lft forever preferred_lft forever
    inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

 

From your logs it would seem that your Ethernet port is not connected. Can you verify.

 

### ip addr: 1: lo: 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 XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever

2: end0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 02:81:1f:4d:3f:5b brd ff:ff:ff:ff:ff:ff

 

I do not understand your comment "If I disconnect it, from a normal operating switch, the OpiOne’s behavior looks the same." Is your "normal" something different than in the failure mode? What is "looks the same"?

 

When you unplug the network can you still interact with he serial port?

[klaute]

With the comment I only want to say that I have tested the behavior with a second switch. 
 

The problem is that if the network cable is reconnected again, the orang pi is still not again available over network. I have to reboot it to have a working network connection.

I try to connect to the serial port later.

 

Thank you for your support! 

Edited April 12 by klaute

[Stephen Graf]

It might also be a good idea to test with another know good Ethernet cable.

[klaute]

The cable is fine. Also tried a different one.

 

I tested it with UART connected to my notebook. The system is available after I have disconnected the network cable.

 

But I can see that some tasks running in docker container after a few seconds cause 100% CPU usage. And the load of the system is growing again and again. I guess that this will kind of „lock“ the device after a few minutes, this tasks are running as root.
 

Thank you for the support and hint with the UART, now I can go on to figure out what the problem is with those tasks…

 

 

[Stephen Graf]

Good luck.