Pedro Lamas

  • Posts

    40
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by Pedro Lamas

  1. 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!
  2. 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!
  3. Pedro Lamas

    Pedro Lamas

  4. 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!!
  5. Thanks @Werner but in my case I'm still on Buster, so my question was more on upgrading from Buster to Bullseye!
  6. 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!
  7. @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"?
  8. @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
  9. 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.
  10. Excellent work @NicoD, does that mean one can now create a PR to improve this and submit to the Armbian repo?
  11. 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!
  12. 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!!
  13. 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?
  14. 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.
  15. @hev can you indicate your current governor settings for comparison (run "cat /etc/default/cpufrequtils" ) ?
  16. 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?
  17. @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 52000 Here'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 ~
  18. 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
  19. 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)
  20. 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!)
  21. 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
  22. @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
  23. 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! Those are the settings I had originally (min 1008000, max 2016000, ondemand), unfortunately I know those make my board to randomly crash!
  24. 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
  25. 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.