Pedro Lamas

Never mind, I just did a regular `apt update && apt upgrade` and got the new fixed kernel up and running, and confirmed this issue is now completely gone!

Please do forgive my ignorance, but I opened `armbian-config`, and on the other kernel I see this: Would the highlighted image do the job? From what I understand that one has the 5.10.63 kernel, so it should have this issue fixed!

Last week I updated the Armbian on my NanoPi M4V2 to the latest version (Armbian 21.08.1 Buster with Linux 5.10.60-rockchip64) and started noticing some issues with my Zigbee2MQTT local install. With the help of the Zigbee2MQTT main developer, we managed to confirm that the issue was reproducible on 5.10.60, but everything was working fine on previous kernels like 5.4. Other users not on Armbian (Raspbian) also confirmed that they were experiencing this problem with the latest kernel but was working fine on previous versions. We realized a bug was introduced for the CH341 driver in 5.10.60, that seems to have been fixed now on 5.10.62. The kernel bug is tracked here: https://bugzilla.kernel.org/show_bug.cgi?id=214131 Z2M is tracking that bug here: https://github.com/Koenkk/zigbee2mqtt/issues/8663 My question now is what can I do to fix this? Is there a way I can rebuild that driver or will this only go away with an upgrade of the kernel? What is the best course of action? Thanks in advance!!

Thanks @Werner but in my case I'm still on Buster, so my question was more on upgrading from Buster to Bullseye!

I assume this involves updating the `/etc/apt/sources.list` file first and then using `apt-get` commands to do the upgrade, but are we ok in doing this or is it recommended that we start freah with a new install? Also, will that also work for users (like me) that are running the OS from an external SSD storage instead of the SD card? Thank you!

@piter75 I've had no issues with my M4V2 since setting the governor to "userspace" and max and min speeds set to "1416000" (and by no issues, I mean no crashes at all and I have an uptime of 20 days now), but I wonder if your fix is for the issues we've seen with the governor set to "ondemand"?

@NicoD uname -a returns "Linux nanopim4v2 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux" Here's my most current armbianmonitor output: http://ix.io/2HmF

Not sure how much it matters or not, but I thought best to point out that I'm actually running Debian Buster and not Ubuntu Focal, plus I run my Nanopi M4V2 completely headless (no screen connected to it) and still experienced the crashes while using the "ondemand" governor.

Excellent work @NicoD, does that mean one can now create a PR to improve this and submit to the Armbian repo?

The alternative to that right now seems to be using a fixed frequency. I personally have been using the "userspace" governor with min and max set to 1416000 and had no crashes at all since I started using those!

I've had a rock solid NanoPi M4V2 since I set the governor to userspace with min and max frequency set to 1416000 - absolutely no crashes at all! I can live with that!!

Thank you for your efforts @zamnuts this is some great info you are sharing! I for one can only say that I've have no issues at all with "userspace" governor and min and max frequency set to 1416000! pedro@nanopim4v2:/sys/devices/system/cpu/cpufreq$ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/scaling_governor userspace userspace pedro@nanopim4v2:/sys/devices/system/cpu/cpufreq$ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/cpuinfo_{cur,min,max}_freq 1416000 408000 1512000 1416000 408000 2016000 My M4V2 has been working for almost 6 days now with 19 docker containers and no problems at all! I understand that ideally one wants to use the "ondemand" governor, but I do wonder what would happen if you run your tests with a "userspace" governor and fixed frequencies?

Following up on the above, I just opened this issue on GitHub, suggesting that the CPUMAX for the RK3399 is set to 1800000 following the manufacturer specifications.

@hev can you indicate your current governor settings for comparison (run "cat /etc/default/cpufrequtils" ) ?