Matthias

It has been a long time since I last posted something in this forum, but I ran into the exact same network stability issues on my NanoPi M4V2 after upgrading to the 6.18 kernel. In my case I even had so many dopped frames that communication was not possible on 1Gbps, only if I switched manually to 100 Mbps. It seems that changes in modern 6.x network drivers cause the inherited rx_delay and tx_delay values to become unstable on this board. After some testing, I found a set of delay values that stabilizes the connection. Given the age of the hardware, I do not think it is a good idea to submit these values upstream into the main kernel, as they might cause regressions on other setups. Instead, using a local Device Tree Overlay (DTO) fixes the issue safely without impacting anyone else. I am sharing the solution here in case others run into the same problem. The Cause In modern kernels like 6.18 the necessary delays on the network interface are done by the PHY hardware, not done by the SoC. This is phy-mode "rgmii-id" (id="internal delay"). Unfortunately that does not seem to work on the NanoPi M4v2. If you try to "patch in" reasonable values for tx_delay and rx_delay via an DTO in the &gmac node, they are ignored if phy-mode is set to "rgmii-id" (as they are supposed to be used by the SoC, which is not responsible in this configuration). Forcing phy-mode = "rgmii"; ensures the kernel hands over the task to the SoC and applies the manual overrides. The stable values for this board turned out to be tx_delay = <0x30>; and rx_delay = <0x24>;. This setup was verified using a full-duplex iperf test at 1 Gbps. Steps to Apply Create a file named eth-fix.dts and add the following content: /dts-v1/; /plugin/; &gmac { phy-mode = "rgmii"; tx_delay = <0x30>; rx_delay = <0x24>; }; Compile and register the overlay using Armbian's built-in tool: sudo armbian-add-overlay eth-fix.dts Reboot the system. This should keep the ethernet connection stable on modern kernels. I hope this is a stable solution for future kernels. Time will tell... But on the other side: rgmii_id is supposed to be more stable than rgmii. So maybe this is just a workaround for a driver issue. But as I said: If the kernel works well for other SoCs, a patch for the (quite old) NanoPi M4v2 might break more modern and more frequently used setups.