Pedro Lamas

Members
  • Content Count

    28
  • Joined

  • Last visited

  1. 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.
  2. @hev can you indicate your current governor settings for comparison (run "cat /etc/default/cpufrequtils" ) ?
  3. 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?
  4. @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
  5. 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
  6. 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)
  7. 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.
  8. 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!!
  9. 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!!
  10. 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!)
  11. 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/
  12. @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
  13. 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!
  14. 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
  15. 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.