TCB13

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.

Could you possibly test it with 4.x on M4v2?

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.

for the LEDs you can try the following:

ls -l /sys/class/leds
(here as example from a NanoPi Neo2):
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr
 
then echo none to the trigger of the led-name: 
 
echo 'none' > /sys/class/leds/[name_of_the_led]/trigger
 
so it should look like this:
 
echo 'none' > /sys/class/leds/nanopi:green:status/trigger
 
You only have to check the led-names of your board and add the commands in /etc/rc.local before "exit 0"

Thank you once again!

Probably ...
To confirm, check it by doing "grep APPARMOR /boot/config-*" .

I try it in kernel 4.4.167.
Thank you for your help.
I am very excited that it can work very well.
But I also try it in the latest kernel 4.20,but get 'don't support the operation'.
I don't know why.
But I can have a good work in the 4.4.167.
Thank you very much!!!

Most Armbian images do not have this problem as well.
 

It should be fixed, but our fix could also be broken - RK3399 has handull of small troubles which is why we actually don't provide end user support yet. When you are approaching with a problem, you always need to provide logs (armbianmonitor -u).

I didn't encounter them by myself, but I think somebody brought up troubles when copying large files via USB3 drives. Check older posts in this subforum.

Problems are outside user space levels otherwise we would notice such problems on other boards, but we don't. Kernel is the king and the troublemaker  

You are using something what was designed for developers and for testing. Neo2 does not have stable builds with mainline kernel yet.
 
This particular error shows that daily automated system is broken and it doesn't provide consistent updates. I am working on fixing it for last two days ... try once again in a week, but beware that you are using unstable kernel, which update might break your system completely. Rather don't upgrade until stable builds are out ...

You are using modern mainline development kernel and those images are experimental. AFAIK this feature is not ported / developed / forgotten to add.