Matthias

I advise sticking with the legacy kernel until the stability issues with the current kernels (specific to the NanoPi M4 V2) have been resolved.

Hallo,
 
I've been using Armbian on the NanoPi M4 V2 for a while and now I'm thinking about switchen from the legacy kernel to the current kernel. Unfortunately that's not so easy to do when using armbian-config. You could think you can just select the current-kernel in the list but you won't find it there. The reason is simple: the legacy kernel belongs to the rk3399-family and the current kernel is rockchip64. Which is basically the same, but from an organisational point of view it is not (please forgive me if I do not show an adequate technical precision here, the details and the plan to clean that up are explained here).
 
What I would be interested in is now: Is there a proper way to switch the kernel manually? As I said, I have been using the system for a while now, so setting it up from scratch with the right kernel is something I would like to avoid.
 
I had a look into the source of armbian-config so I know that manipulating the LINUXFAMILY in /etc/armbian-release will display the current-kernel in the list. But I don't want to imagine what kind of side-effects will hit me when starting the installation process that way.
 
Cheers,
 
 
Matthias

This is good but let's see if it keeps being stable.
I still think that we are covering up for some other issue with this cpu frequency governor behaviour change 

I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
But of course, that's not a prove against crashes...

I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
But of course, that's not a prove against crashes...

@Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.

Interesting, I also had problems copying files using the 5.4 kernel on my NanoPi M4V2. I compiled it myself and copies files from the sd-card to and external hard drive connected via the SATA-hat. I used file systems on the hard drive that were able to detect corrupted data on the drive (ZFS and BTRFS) and every time I did a scrub after copying the files, failed CRC-checks within the data were reported, some of them even at the same position on two redundant drives (mirror).
 
I'll try again with the legacy kernel (4.x). Would be greate if it works in this configuration. @piter75: Did you apply your fixes for ethernet also to the legacy kernel? Then it would be much easier to get the data onto the device in the first place.

I have taken another route with this PR.
I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
Higher MTUs would require further shortening of the PBL.
 
I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.

This cleaning can be done here: https://github.com/armbian/build/blob/master/lib/makeboarddeb.sh#L176-L227 and it will happen withing update.

Some further observations of mine in case it helps identifying the problems using ethernet: After noticing that the throughput using the native ethernet connection (eth0) of the M4V2 is low, I checked it using iperf3. I tested the legacy kernel, the current kernel and the dev kernel. The results are quite interesting:
 
Legacy kernel: Can receive data via TCP  from anoter host with high speed (~940MBit/s) but the other way around is quite slow (<1MBit/s).
Current/dev kernel: Can send data via TCP to another host with high speed (~950MBit/s) but the other way around is quite slow (~3MBit/s).
 
Further information:
If I set the link speed to 10MBit half duplex there seems to be almost no packet loss that slows down the connection. Using a USB3-ethernet adapter speed is good in both directions. I did not care about WiFi. It's not connected. There is a SATA hat attached to my NanoPi M4V2. Only power supply is used, no hdds are connected. Of course I only have one device at hand, so I cannot guarantee that the behavior is representative. Generally: If there is somebody working on further bringup of NanoPi M4V2 and needs somebody for testing, I'm happy to assist.