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)

Hello again.

I managed to go back to sysvinit with my Trixie setup. Then I tried different kernel versions 6.5.7, and then from 6.12.6 up to 6.17.7. With all versions eth0 comes up, except for 6.17.17.

To verify this, I did a clean install on a USB SSD, with the Nov 2023 image (Bookworm), and tried the same kernels, with the same results. I would say that the issue is not in systemd but elsewhere.

Bootlog of 6.17.7 shows one particularity compared to 6.15.5, at around 23-24 seconds into boot, that after

ifup

with 6.17.7 the adapter does not enter in 1000 MB/s full duplex but stays in 10 MB/s half duplex.

1c1
< bootlog-6.15.5-ssd
---
> bootlog-6.17.7-ssd
61c61

< [   24.386184][  T828] mv643xx_eth: Set the PHY back to auto-negotiation mode
< [   24.386731][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
< [   24.404305][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
< [   24.411145][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
< [   24.421793][   T49] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registered for speed(1000)
---
> [   23.879517][  T823] mv643xx_eth: Set the PHY back to auto-negotiation mode
> [   23.879718][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control enabled
> [   23.897215][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
> [   23.905085][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 10 Mb/s, half duplex, flow control disabled
431c422
< [   27.539709][   T49] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registered for speed(1000)
---
> [   24.985679][   T41] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registered for speed(10)
438c429]

When I do

ifdown -a && ifup -a

the interface comes up after all:

root@debian:~# ifdown -a && ifup -a
[   76.026350][ T1099] mv643xx_eth: Set the PHY back to auto-negotiation mode
[   76.026780][    C0] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 10 Mb/s, half duplex, flow control disabled
root@debian:~# [   79.145766][    T8] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registered for speed(1000)

root@debian:~#

So far this update.

Maarten

MaartenJD,

I don't see this network problem on my NSA325 running 6.17.7 and sysvinit.

And

root@debian:~# [   79.145766][    T8] mv643xx_eth_port mv643xx_eth_port.0 eth0: No phy led trigger registered for speed(1000)

The above was not an error. Just a warning that the LED trigger is not registered so the port LED cannot be set. The NIC should be running fine without the trigger.

Do this experiment: use the workaround (ifdown/ifup) to bring up the network. Log in with SSH. And remove the work around. Reboot. See if the network is brought up and you can log in with SSH.

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