Pedro Lamas

  • Content Count

    35
  • Joined

  • Last visited

About Pedro Lamas

  • Rank
    Advanced Member
  1. @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"?
  2. @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
  3. 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.
  4. Excellent work @NicoD, does that mean one can now create a PR to improve this and submit to the Armbian repo?
  5. 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!
  6. 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!!
  7. 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
  8. 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.
  9. @hev can you indicate your current governor settings for comparison (run "cat /etc/default/cpufrequtils" ) ?
  10. 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?
  11. @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
  12. 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
  13. 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!!
  14. 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!)
  15. 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/