NSA325 Linux 6.17.7 eth0 not coming up after poweroff

Hello.

Thanks Bodhi and others for your continued efforts to keep older devices alive and useful and my best wishes for 2026.

I don't know whether this issue started after upgrade to the 6.17.7 kernel. When I boot up my NSA325 (with U-Boot 2023.04-tld-1) after a shutdown/poweroff, eth0 does not come online by itself. After a hot reset the issue is not there.

See attached file for the entire boot log. Observation in the boot sequence is that Job networking.service is taking more than a minute; please ignore the 15 seconds; it truly takes more than a minute:

[    4.915480][    T1] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[    4.924261][    T1] mv643xx_eth: Set the PHY to fix link down
[    4.925012][    T1] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address e8:37:7a:2d:xx:yy
.
.
.
[  OK  ] Finished ifupdown-pre.serv… synchronize boot up for ifupdown.
Starting networking.service - Raise network interfaces...
[   40.532524][  T388] mv643xx_eth: Set the PHY back to auto-negotiation mode
[   40.532752][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control enabled
[   40.550312][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[   40.562958][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 10 Mb/s, half duplex, flow control disabled
[***   ] Job networking.service/start running (15s / 5min 12s)
[   43.681318][    T6] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registe
[  OK  ] Finished networking.service - Raise network interfaces.
[  OK  ] Reached target network.target - Network.
[  OK  ] Reached target network-online.target - Network is Online.

ifconfig shows no ip4-address for eth0

root@debian:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ea37:7aff:fe2d:e633  prefixlen 64  scopeid 0x20<link>
        inet6 2001:1c04:3b11:d8f0:ea37:7aff:fe2d:e633  prefixlen 64  scopeid 0x0<global>
        inet6 fd5c:5b3a:698e:0:ea37:7aff:fe2d:e633  prefixlen 64  scopeid 0x0<global>
        inet6 fdb6:8443:8f8f:0:ea37:7aff:fe2d:e633  prefixlen 64  scopeid 0x0<global>
        ether e8:37:7a:2d:e6:33  txqueuelen 1000  (Ethernet)
        RX packets 902  bytes 164720 (160.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 47  bytes 9012 (8.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 31  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 12  bytes 1710 (1.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 1710 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Only after doing a manual

ifdown eth0 && ifup eth0

or

systemctl restart networking

it acquires an ip-address via dhcp.

For now I have put

systemctl restart networking

in my rc.local as an effective intermediate solution.

Might the cause of this issue have something to do with the link-down fix (at 4.92 seconds, hardware or driver related)

ifupdown-pre.serv… synchronize boot up for ifupdown

at 40.53 seconds or is it systemd-related (e.g wrong commands, dependencies or sequences)?

MaartenJD,


> Might the cause of this issue have something to do
> with the link-down fix (at 4.92 seconds, hardware
> or driver related)
>

> ifupdown-pre.serv… synchronize boot up for
> ifupdown
>

> at 40.53 seconds or is it systemd-related (e.g
> wrong commands, dependencies or sequences)?

It's systemd. Looks like the init sequence has a lot more going on than using sysvinit (which is working fine).

Below is the output of a hardcoded patch I've implemented long ago in the kernel to bring up the network for this board (what the stock OS does).

[    4.924261][    T1] mv643xx_eth: Set the PHY to fix link down
[   40.532524][  T388] mv643xx_eth: Set the PHY back to auto-negotiation mode

The long term solution is to implement it properly in the DTS if possible (so it works for both sysvinit and systemd).


> For now I have put
>

> systemctl restart networking
>

> in my rc.local as an effective intermediate
> solution.

Good work around for now.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hello Bodhi and other members.

I did some troubleshooting by comparing the bootlog (irrelevant lines removed) with a tcpdump on my router (filtering on the MAC-address of my NSA325), with the rc.local activation in place. The clocks were quite in sync.

rc.local kicks in at 11:18:15. Not until 11:18:25 (1m 29s after starting the kernel boot) there is a first activity on the LAN-port.

The bootlog says that around 11:17:12 the first dhcp-requests are sent but actually nothing goes out, it seems.

I upgraded to Trixie but that made things worse, because rc.local is treated differently there and starts halfway ohter systemd-services with netwerk focus. I will write a seperate systemd-service that surely starts at the end of the boot process. And I will install orphan-sysvinit-scripts, to see if I can revert to sysvinit.

Also I will create an entirely fresh boot disk with the 6.12.6 kernel and the Debian-6.5.7-kirkwood-tld-1-rootfs, to see if things are different there. And then slowly move up the updates.

That's it for now. I will keep you posted.
Maarten

Maarten,

Sounds like a good plan.

BTW, please convert your log files to .txt before posting here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)