Pedro Lamas
-
Posts
40 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Pedro Lamas
-
-
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!
-
Armbianmonitor:
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!!
-
-
On 9/3/2021 at 11:14 AM, Igor said:
yes.
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!
-
-
@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.
-
-
3 minutes ago, svenoone said:
Hey @NicoD,
Thank you for your note, I never tested the Legacy images, i will give them a try, but I am not happy with that
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 2016000My 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?
-
On 9/30/2020 at 2:34 PM, Pedro Lamas said:
I just noticed something while reading at the RK3399 specsheet: the recommended maximum frequency of the A72 is actually 1.8Ghz, not 2.0Ghz as on the FriendlyARM website and wiki!
The RK3399K however does indicate a recommended maximum of 2.0Ghz, but that is not the version in use on the NanoPi M4V2.
The Rock Pi 4 uses the same RK3399 SoC and they specifically say the frequency of the A72 is 1.8Ghz.
I even found a commit in armbian codebase for the Helios64 (another one with the same RK3399 SoC) where the maximum is set to 1.8Ghz: https://github.com/armbian/build/pull/2191
I will leave my board for a couple of days more with "userspace" governor and min and max set to 1008000, and if there's no crashes, I will try "ondemand" governor with min set to 1008000 and max to 1800000
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.
-
-
So having the governor set to "userspace" with min and max speed set to "1200000" seems to make it completely stable.
Any idea of what we can try next?
As the Helios64 shares the same CPU, I do ask if it is running more stable than the M4V2... if it is, any chance of comparing the two and trying to make the M4V2 settings match the ones on the Helios64?
-
@piter75 having made the overlay change you suggested (be aware I'm now using "userspace" governor fixed to 1200000), shouldn't cpu4 and cpu5 return 40000 instead of the current 52000?
pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency 40000 pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency 40000 pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_transition_latency 40000 pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency 40000 pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_transition_latency 52000 pedro@nanopim4v2:~$ cat /sys/devices/system/cpu/cpu5/cpufreq/cpuinfo_transition_latency 52000Here's the full output for cpu4:
pedro@nanopim4v2:~$ pushd /sys/devices/system/cpu/cpu4/cpufreq && paste <(ls *) <(cat *) && popd /sys/devices/system/cpu/cpu4/cpufreq ~ affected_cpus 4 5 cpuinfo_cur_freq 1200000 cpuinfo_max_freq 2016000 cpuinfo_min_freq 408000 cpuinfo_transition_latency 52000 related_cpus 4 5 scaling_available_frequencies 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 scaling_available_governors conservative userspace powersave ondemand performance schedutil scaling_cur_freq 1200000 scaling_driver cpufreq-dt scaling_governor userspace scaling_max_freq 1200000 scaling_min_freq 1200000 scaling_setspeed 1200000 cat: stats: Is a directory stats: reset time_in_state total_trans trans_table ~
-
I've had enough crashes with the 40000 overlay change, so for now I've moved back to what I hope are safer governor settings:
pedro@nanopim4v2:~$ cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=1200000 MAX_SPEED=1200000 GOVERNOR=userspace
-
Thanks for sharing that @piter75, following your instruction I've now added the overlay and set the governor back to "ondemand" with min 600000 and max 1800000.
I'll keep an eye on it and report back any crash - hopefully not though!!
Entering day 3 with "ondemand" governor, min 600000 and max 1800000, and the custom overlay @piter75 provided... no issues at all!! I think we're on to something here!!
I just woke up to find my M4V2 had crashed during the night...
As I had to manually reboot it, I upgraded the firmware via armbian-config and rebooted it again to make sure I'm using the latest available.
Another crash just now while I was pulling some images from Docker Hub...
Message from syslogd@localhost at Oct 7 18:13:28 ... kernel:[85530.199864] Internal error: Oops: 96000044 [#1] PREEMPT SMP Message from syslogd@localhost at Oct 7 18:13:28 ... kernel:[85530.221095] Code: f94006e1 f9403fe2 f90004e1 d37cf400 (f9000027) -
3 hours ago, aprayoga said:
We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.
Hi @aprayoga thank you for your comments, I will check on this though at this moment I don't know how I can apply that 40000 value (I assume this is not an easy change to cpufrequtils!)
-
I just noticed something while reading at the RK3399 specsheet: the recommended maximum frequency of the A72 is actually 1.8Ghz, not 2.0Ghz as on the FriendlyARM website and wiki!
The RK3399K however does indicate a recommended maximum of 2.0Ghz, but that is not the version in use on the NanoPi M4V2.
The Rock Pi 4 uses the same RK3399 SoC and they specifically say the frequency of the A72 is 1.8Ghz.
I even found a commit in armbian codebase for the Helios64 (another one with the same RK3399 SoC) where the maximum is set to 1.8Ghz: https://github.com/armbian/build/pull/2191
I will leave my board for a couple of days more with "userspace" governor and min and max set to 1008000, and if there's no crashes, I will try "ondemand" governor with min set to 1008000 and max to 1800000
-
@Werner just a thought but the NanoPi M4V2 has an RK3399 SoC , so it has a Dual-Core Cortex-A72(up to 2.0GHz) and a Quad-Core Cortex-A53(up to 1.5GHz)... does the "ondemand" governor handle these two CPU's separately?
The datasheet does mention they work with different voltages: http://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
-
15 hours ago, hexdump said:
maybe that helps, but running this board at only 1 ghz sounds a bit strange
Indeed, but I'm just doing this as a test and seeing how things go... I want to take full advantage of this boards, but something must be going terribly wrong for it to randomly crash and maybe this is a step in the right direction to find out what it is and how to mitigate it!
10 hours ago, piter75 said:With one of my boards I have had good results with min set to 1008000 and max to 2016000 (ondemand governor). You could also try that range.
However the other one is still unstable in this scenario but runs stable with performance governor (meaning 2016000 all the time).
Those are the settings I had originally (min 1008000, max 2016000, ondemand), unfortunately I know those make my board to randomly crash!
-
On 9/28/2020 at 4:44 AM, Werner said:
You could also try to set userspace as govenor and put the min an max frequency at the same values. performance basically means to set them to the highest possible.
I've changed it to 1008000 yesterday, so far all good (though obviously a bit slower):
pedro@nanopim4v2:~$ cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=1008000 MAX_SPEED=1008000 GOVERNOR=userspace -
On 9/26/2020 at 12:09 PM, Werner said:
Interesting. So there might be an issue with clock changes (DVFS)?
Not sure how relevant this might be, but after checking around on previous reports on issues with the governor on the nanopi m4v2, I found this post and it actually mentions that "on demand" is causing issues... looking further down, I see bug reports that are quite similar to my own experience.
My system is currently set to "on demand" (never changed it, so I assume this is the default), I might give it a try and set it to "performance" or some other values and test with that.
-
Not sure what the governor is or how I can change it (granted, haven't looked into the docs yet) but if there's any setting I can change to test I'll be willing to do just that!
At the moment, the best I've seen my nanopi m4v2 work without crashing was about 3 days, but on average I have to reboot it daily...
Bug on Kernel 5.10.60 with CH341 driver
in Rockchip
Posted
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!