Rock64 - sudden default route loss

Troubleshooting
1

Hello.

Running a Rock64 for several month on DietPi.
It’s currently running v9.8.0.

The Rock64 is hosted in a datacenter (in my rack), I was connected to it from home.
Suddenly I lost access to the device. No more ssh, no more ping, nothing.

After a bit of digging I found out I could still connect to it from another of my servers (hosted in the same rack), as long as they were in the same subnet.

So I eventually got a session on the Rock64.

$ sudo ip route show
xxx.yyy.zzz.aaa/25 dev eth0 proto kernel scope link src qqq.sss.ddd.fff

And that’s all.
The IP is correct, the subnet is correct but no more default route.

So I added the default route back:

$ sudo ip route add default via xxx.yyy.zzz.bbb

It worked immediately (can be pinged or sshed into).

$ sudo ip route show
default via xxx.yyy.zzz.bbb dev eth0
xxx.yyy.zzz.aaa/25 dev eth0 proto kernel scope link src qqq.sss.ddd.fff

Here’s the content of the syslog at the time the issue happened:

2025-03-11T14:18:55.332302+01:00 bag kernel: [1234689.343316] rk_gmac-dwmac ff540000.ethernet eth0: NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 8740 ms
2025-03-11T14:18:55.332477+01:00 bag kernel: [1234689.343659] rk_gmac-dwmac ff540000.ethernet eth0: Reset adapter.
2025-03-11T14:18:55.340083+01:00 bag kernel: [1234689.349925] rk_gmac-dwmac ff540000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
2025-03-11T14:18:55.408114+01:00 bag kernel: [1234689.415368] rk_gmac-dwmac ff540000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=POLL)
2025-03-11T14:18:55.416127+01:00 bag kernel: [1234689.425492] rk_gmac-dwmac ff540000.ethernet eth0: No Safety Features support found
2025-03-11T14:18:55.416195+01:00 bag kernel: [1234689.425538] rk_gmac-dwmac ff540000.ethernet eth0: PTP not supported by HW
2025-03-11T14:18:55.416212+01:00 bag kernel: [1234689.425570] rk_gmac-dwmac ff540000.ethernet eth0: configuring for phy/rgmii link mode
2025-03-11T14:18:59.528121+01:00 bag kernel: [1234693.536915] rk_gmac-dwmac ff540000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I already happened in January (two months ago), I “fixed” it by a hard reboot (remote hands).
But the log (after reboot) showed the Rock64 was alive, it was just a network issue.

So it happened twice.
On first time the Rock64 was running DietPi in December 2024 version (can’t remember the numbers).

2

Do you use the dietpi-config to configure network?
Is it DHCP or Static?
What is the output of:
cat /etc/network/interfaces; head -n -0 /etc/network/interfaces.d/*

3

The network configuration was made at first boot using the dietpi.txt file and did not modify it since.

$ cat /etc/network/interfaces
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/

# Drop-in configs
source interfaces.d/*

# Ethernet
allow-hotplug eth0
iface eth0 inet static
address qqq.sss.ddd.fff
netmask 255.255.255.128
gateway xxx.yyy.zzz.bbb
dns-nameservers 9.9.9.9

$ head -n -0 /etc/network/interfaces.d/*
head: cannot open '/etc/network/interfaces.d/*' for reading: No such file or directory
4

I don’t see why dietpi would have something to do here, as the networking part is following the standard of the underlying Debian OS.
Maybe @Joulinar or @MichaIng can comment about the watchdog, but I don’t think it is something dietpi specific.

5

nope you are right @trendy
Network stack should be pure Debian tools.

6

Looks like a pretty generic thing which can happen for various reasons with various Ethernet adapters: Kernel errors "kernel: NETDEV WATCHDOG: eth0: transmit timed out" - Red Hat Customer Portal

I have a new kernel build in the pipeline to test, just in case it is a kernel/driver bug:

cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-rockchip.deb
sudo dpkg -i linux-{dtb,image}-current-rockchip.deb
sudo reboot

Otherwise check. pysical cable connections and try disabling checksums as suggested on the (old but still valid) RHEL page.

7

This topic was automatically closed 178 days after the last reply. New replies are no longer allowed.