Radxa Zero 3E: ~87% packet loss on eth0 after dietpi-update

[ilmax]

Summary

After running dietpi-update on 2025-04-19, the Radxa Zero 3E loses virtually all Ethernet connectivity. The interface comes up, IP is assigned, ARP resolves, and the physical link is at 1 Gbps/Full — but
approximately 87% of packets in both directions are dropped (1 successful ping out of every ~8 attempts). The device is unreachable except via a KVM-over-IP console.

Hardware

• Board: Radxa Zero 3E (RK3566 SoC)
• NIC driver: rk_gmac-dwmac (fe010000.ethernet)
• Network config: Static IP via /etc/network/interfaces

Software

• OS: DietPi (updated to latest on 2025-04-19)
• Kernel: 6.18.22-current-rockchip64
• Previous kernel: what was included in the version 10.2.3

Steps to Reproduce

1. Start from a working DietPi installation on Radxa Zero 3E with static Ethernet
2. Run dietpi-update
3. Reboot

Expected Behavior

Ethernet works as before — full connectivity, no packet loss.

Actual Behavior

• ip link show eth0: interface is UP, LOWER_UP
• ip addr show eth0: correct static IP assigned (192.168.x.x/24)
• ip route show: correct default route present
• dmesg: rk_gmac-dwmac ... eth0: Link is Up - 1Gbps/Full - flow control rx/tx
• ip neigh show: gateway ARP entry resolves (STALE, not FAILED)
• ping : 100% packet loss from SBC
• Ping from router to SBC: ~1/8 packets succeed (~87% loss)
• ip -s link show eth0: TX and RX counters grow, but TX dropped counter increases during ping (~6 drops per 14 packets in one test run)
• No firewall present (nft, iptables, dietpi-firewall all absent/not found)

Relevant dmesg output

  [  1.469652] rk_gmac-dwmac fe010000.ethernet: IRQ sfty not found
  [  1.470146] rk_gmac-dwmac fe010000.ethernet: integrated PHY? (no)
  [  1.475234] rk_gmac-dwmac fe010000.ethernet: init for rgmii-id with delay (tx: 0x0, rx: 0x0)
  [  1.475769] rk_gmac-dwmac fe010000.ethernet: User ID: 0x30, Synopsys ID: 0x51
  [  1.475813] rk_gmac-dwmac fe010000.ethernet: DWMAC4/5
  [  1.476117] rk_gmac-dwmac fe010000.ethernet: TSO supported
  [  1.476150] rk_gmac-dwmac fe010000.ethernet: Enable RX Mitigation via HW Watchdog Timer
  [  1.476183] rk_gmac-dwmac fe010000.ethernet: Enabled RFS Flow TC (entries=10)
  [ 10.160985] rk_gmac-dwmac fe010000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
  [ 10.164507] rk_gmac-dwmac fe010000.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] (irq=POLL)
  [ 10.180474] rk_gmac-dwmac fe010000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
  [ 14.274113] rk_gmac-dwmac fe010000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Workaround Attempts

• Rebooted SBC: no change
• Rebooted router: no change
• Removed and re-added device in Unifi controller (clears ARP/DHCP state): no change
• ethtool -K eth0 gro off gso off tso off — could not test (ethtool not installed, no network to install it) no change

Any suggestion would be greatly appreciated

[MichaIng]

Generally, the kernel is independent of the DietPi version. You can downgrade if needed:

apt policy linux-image-current-sunxi64 # to list available versions
sudo apt install linux-{image,dtb}-current-sunxi64=<version>

Did you remove ethtool manually? It should be pre-installed on all our images.

Anyway, I have a 3E here and can try to replicate. I have such a feeling that this issue is related to the Ethernet issues on the Orange Pi Zero 2W extension board, that we needed to fix as well in Linux 6.18.

If you find time, could you downgrade the kernel, and paste the same dmesg output + comparison of lsmod? I want to see whether the same drivers are/were used.

[ilmax]

apt policy linux-image-current-sunxi64
Notice: Unable to locate package linux-image-current-sunxi64

Did you remove ethtool manually? It should be pre-installed on all our images.

Actually, I think, I may have mispelled it (or JetKVM got in my way) anyway, after disabling network offload features as per the command in the previous post - which I will update - network is still dead.

If you find time, could you downgrade the kernel, and paste the same dmesg output + comparison of lsmod? I want to see whether the same drivers are/were used.

More than willing to try something, but I may need some guidance because this is a bit outside my comfort zone. Also (maybe it's obvious, but stating it anyway for clarity, I can't get apt to install tools/things over the internet.

[MichaIng]

Hmm, it actually works well here:

root@DietPi:~# uname -a
Linux DietPi 6.18.22-current-rockchip64 #1 SMP PREEMPT Sat Apr 11 12:26:52 UTC 2026 aarch64 GNU/Linux
root@DietPi:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.639 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.797 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.598 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.603 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.632 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.659 ms
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5068ms
rtt min/avg/max/mdev = 0.598/0.654/0.797/0.066 ms
root@DietPi:~# echo $G_HW_MODEL_NAME
Radxa ZERO 3 (aarch64)
root@DietPi:~# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether XXXX brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.15/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2003:XXXX/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 172771sec preferred_lft 86371sec
    inet6 fe80::XXXX/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

And from another system, pinging the ZERO 3E:

C:\Windows\System32>ping 192.168.1.15

Ping wird ausgeführt für 192.168.1.15 mit 32 Bytes Daten:
Antwort von 192.168.1.15: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.15: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.1.15: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.1.15: Bytes=32 Zeit=1ms TTL=64

No package loss.

On the one hand, I am happy it is not a general issue, on the other hand this makes it difficult for me to debug your case. Can you verify that you are on very same kernel package version?

root@DietPi:~# dpkg -l linux-image-current-rockchip64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                           Version               Architecture Description
+++-==============================-=====================-============-=============================================================
ii  linux-image-current-rockchip64 26.05.0-trunk-dietpi1 arm64        Armbian Linux current kernel image 6.18.22-current-rockchip64

Btw, I mixed things up regarding Orange Pi Zero 2W and linux-image-current-sunxi64: The Radxa ZERO 3 uses a Rockchip RK3566 SoC, no Allwinner one, hence the two issues are unrelated.

[ilmax]

I verified that the kernel package is the same version as yours.
I found an interesting thing, if I force the eth0 interface to 100 fullduplex via:

ethtool -s eth0 speed 100 duplex full autoneg off

Then it works again, I can reach out and I can also ssh into the machine. That's unfortunate, though, given the SBC has a 1gb nic.

Edit

Actually, after doing the following:

ifdown eth0 && ifup eth0

The SBC is back online, but after a reboot, it's dead once again

[ilmax]

With the help of claude code, I was able to recompile the device tree and add the missing tx_delay and rx_delay that I got from the official radxa linux v6.1, and the problem is fixed now, in the 6.18 these values are missing from the dtsi file.

This is strange, though, because I seem to remember I was already on 6.18 even before the update to the latest DietPi version.

[MichaIng]

Already in Linux 6.12 (mainline), the PHY was operated in rgmii-id mode, where rx_delay/tx_dalay are not needed, but passed by the PHY: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3e.dts?h=linux-6.12.y
However, they are still sometimes defined, and add on top of the delays passed by the PHY, AFAIU.

Checking all includes and Armbian patches in Linux 6.12: https://github.com/search?q=repo%3Aarmbian%2Fbuild+path%3A%2F%5Epatch%5C%2Fkernel%5C%2Farchive%5C%2Frockchip64-6%5C.12%5C%2F%2F+%2Ftx_delay%2F&type=code&p=1
=> I do not see delays being defined their end either, for the Radxa ZERO 3(E) or RK3566 in general.

Radxa's vendor kernel has it, but also runs the PHY in rgmii mode: https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr5.1/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero3.dtsi#L444-L464
Taking these same values with mainline kernel and rgmii-id should result in unnecessary long delays. However, if it fixes things for you, you seem to have a bad individual board which requires it. And on Linux 6.12, there probably was a subtil difference in device init/timing so that it worked.

I'll keep that in mind, if more people report the same issue, we could add some small delays as safety net.

... hmm I se now it is a RTL8211F chip. For this, we applied a different fix in some other cases: MichaIng/build@c31a8e9
Since network does initialize in your case, but you just see high package losses, the RX/TX delays however seem the right approach. If the reset fails, it wouldn't work at all.

I'll leave the issue open, in case others face the same, but otherwise won't apply a device tree patch for a single case. You might want to turn your change into a device tree overlay, but that to /boot/overlay-user/*.dtbo, and set it in /boot/dietpiEnv.txt via user_overlays= setting, using the filename without .dtbo extension. That way, it survives kernel upgrades.

[ilmax]

Thank you for the explanation. I just flashed a brand new dietpi OS on the boards (latest version avaiable from the website download), hoping this would fix my problem, but that's not the case. Network is still dead and downgrading eth speed to 100 fixes it.

Now I do not understand why 2 out of 2 of my Radxa Zero 3e boards are dead, while your work 😄

Anyway, I will try to figure out how to create the overlay so this doesn't happen.
Thank you again for looking into this!

[MichaIng]

Okay, I didn't know that it is the same in 2/2 of your boards. If downgrading to 100 MiB helps as well, it might be also related to your network/router, but RX/TX delays should then have no effect, AFAIK 🤔.

For the overlay:

apt install device-tree-compiler
mkdir -p /root/overlay-user
cd /root/overlay-user
cat << '_EOF_' > ethernet.dtbs
/dts-v1/;
/plugin/;
&rgmii_phy1 {
	tx_delay = <0x47>;
	rx_delay = <0x27>;
}
_EOF_
dtc -I dts -O dtb -o ethernet.dtbo ethernet.dtbs
G_CONFIG_INJECT 'user_overlays=' 'user_overlays=ethernet' /boot/dietpiEnv.txt

The two values seem to be <71> and <39>, quite small already.

[ilmax]

ah, worth probably the connection speed matters, I am connected to a UniFi switch at 1 GB speed

[MichaIng]

In my case it is a 1 Gbit network as well. But maybe there is some issue with the combination of the SBC Ethernet adapter, the switch and/or router with Gbit speed. I remember another case where some SBC had issues with Gbit network, but worked well with 100 Mbit, and no one else could replicate this. So LAN/switch/cable seem to be the only difference then, if it is not the particular board from a bad production line or so.

So with the RX/TX delay change, does it work well with GBit speed? Just in case, also verify the overlay has been applied successfully:

ls -l /proc/device-tree/ethernet@fe010000/mdio/ethernet-phy@1/[rt]x_delay

I hope I got that path right 😄.