Sorry I'm not able to find the sub category for M4V2 so I chose R4S instead. But please keep in mind that this is a bug report for NanoPi M4V2.

 

So my box has been running well for 5 years without any issue, through multiple system upgrade from armbian buster to trixie. However after I upgrade the kernel from 6.12.58 to 6.18.10 just a couple of days ago, the system started to have some weird behavior. The main symptom is that I'll lose the network connection from the box once it starts up, and it could happen after just a few minutes, or a couple of hours. I have to power cycle the box to get it back online as I don't have any peripherals, and soon I will lose the connection again.

 

Other symptoms I've observed so far:

- Once I lost the connection and powered cycle the box, the timestamp in the log looks confusing. Somehow the system clock paused at the moment when system froze. When it boots up, there could be a large gap between the NTP server and it will have to sync up, and I don't even seem to be able to find any logs before this reboot

- The line `fdtfile=rockchip/rk3399-nanopi-m4v2.dtb` in `/boot/armbianEnv.txt` looks to be missing, so I added it back but it didn't fix the issue

 

Eventually I downgraded to 6.12.58 with armbian-config, by timing the time window between the bootup and system freeze. After that the issue seems to be gone. Please find the results for `armbianmonitor -u` at https://paste.armbian.com/werujijedo

 

For those who has the same model as mine, please think twice before upgrading. Do backup your data if you'd like to take the risk.

logs are incomplete. dmesg is missing completely which would be the most relevant.

 

moved to staging

Attaching the kernel log see if it helps.

 

kern.log.1

The output still seems truncated. Perhaps leave the device running for a while with the broken kernel (I suggest to build your own kernel package for either "current" or "edge" to rule out that this hasn't been solved in the mean time by something else) to catch multiple of these connection drops. Also add verbosity=8 to your /boot/armbianEnv.txt to catch as much data as possible.

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.

Edited July 29Jul 29 by Matthias