Pedro Lamas

  • Posts

    40
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Pedro Lamas reacted to Werner in Bullseye: Automatic upgrade when unstable becomes stable?   
    Unfortunately userspace upgrades like Bionic to Focal or Stretch to Buster have never been officially supported by Armbian due to lack of resources for proper testing. It probably works if you freeze your firmware packages and follow official Ubuntu/Debian guide how to upgrade but if something goes wrong you won't receive help from Armbian.
  2. Like
    Pedro Lamas reacted to Werner in Bullseye: Automatic upgrade when unstable becomes stable?   
    No. If you run bullseye simply wait until rootfs updates support status to supported. Things are prepared already: https://github.com/armbian/build/commit/f61f560510b8a4ba012209f27c0b3e44909232ef
  3. Like
    Pedro Lamas reacted to piter75 in Randoms reboot NanoPi M4V2   
    With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in.
    My experience is that you could also set it to min/max 2GHz and it would be just as good.
     
    Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor.
     
    It seems that the instability of little core's voltage during the voltage change was the issue.
    Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still unstable).
    It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.
  4. Like
    Pedro Lamas got a reaction from Igor in Randoms reboot NanoPi M4V2   
    @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"?
  5. Like
    Pedro Lamas got a reaction from NicoD in NanoPi M4V2 randomly crashes   
    Excellent work @NicoD, does that mean one can now create a PR to improve this and submit to the Armbian repo?
  6. Like
    Pedro Lamas reacted to NicoD in NanoPi M4V2 randomly crashes   
    Update : It was a mesa bug that produced the crashes. 
    RK3399 is now back stable with latest updates. Even at 2Ghz and ondemand governor. 
    But not all problems are fixed yet with mesa/panfrost. The errors in dmesg are still there. And some things that use panfrost will not work. 
    Mesa has had a major update to version 20.2.4. So if you need panfrost, best to use mesa 20.2.3. https://docs.mesa3d.org/relnotes/20.2.4.html
    You can also download the old version of Armbian Reforged with mesa 20.2.3. But be sure not to upgrade for the moment. 
     
  7. Like
    Pedro Lamas reacted to zamnuts in NanoPi M4V2 randomly crashes   
    I noticed that the ondemand sampling_rate was low in 5.x compared to 4.4's default. compare below:
     
    $ uname -r 4.4.213-rk3399 $ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/ondemand/sampling_rate 40000 465000  
    vs
     
    $ uname -r 5.8.15-rockchip64 $ sudo cat /sys/devices/system/cpu/cpufreq/policy{0,4}/ondemand/sampling_rate 10000 10000  
    It appears that 10000 seems to be a default (or the minimum value possible). Per https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt 10000 is too low given the cpu_transition_latency:
    $ uname -r 5.8.15-rockchip64 $ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency 40000 40000 40000 40000 515000 515000  
    Given the documented formula cpuinfo_transition_latency * 750 / 1000, it should be (at a minimum) 30000 for cpu0-3, and 386250 for cpu4-5.
     
    Using sysfs to configure cpufreq on boot with the revised sampling_rate seems to make it stable (although uptime is only about 2 days in). I ran periodic load testing to get the ondemand governor to change freq, and this config looks promising. Despite the previously mentioned calculations, i opted to align the sampling_rate with what was present in the 4.4 kernel:
    $ tail -n+1 /etc/sysfs.d/* ==> /etc/sysfs.d/cpufreq-policy0.conf <== devices/system/cpu/cpufreq/policy0/scaling_governor = ondemand devices/system/cpu/cpufreq/policy0/scaling_max_freq = 1416000 devices/system/cpu/cpufreq/policy0/scaling_min_freq = 600000 devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate = 40000 ==> /etc/sysfs.d/cpufreq-policy4.conf <== devices/system/cpu/cpufreq/policy4/scaling_governor = ondemand devices/system/cpu/cpufreq/policy4/scaling_max_freq = 1800000 devices/system/cpu/cpufreq/policy4/scaling_min_freq = 600000 devices/system/cpu/cpufreq/policy4/ondemand/sampling_rate = 465000 $ for i in 0 1 2 3 4 5; do sudo cat /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_{governor,min_freq,max_freq}; done; ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1416000 ondemand 600000 1800000 ondemand 600000 1800000  
    one of two boards are already crashing, not sure if its the board or what. going to switch to "performance" governor and see. figured i'd share the sample_rate delta info though.
  8. Like
    Pedro Lamas reacted to hev in NanoPi M4V2 randomly crashes   
    @Pedro Lamas I don't use this to config. my config equivalent to:
    echo 1416000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq echo 1800000 > /sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor echo performance > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor  
  9. Like
    Pedro Lamas got a reaction from aprayoga in NanoPi M4V2 randomly crashes   
    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)  
  10. Like
    Pedro Lamas reacted to piter75 in NanoPi M4V2 randomly crashes   
    @aprayoga Fingers crossed!
    I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful).
    I started some tests with 40000 right now.
     
    @Pedro Lamas if you want to also try testing it...
    Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2.
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };  
  11. Like
    Pedro Lamas reacted to aprayoga in NanoPi M4V2 randomly crashes   
    @piter75 @Pedro Lamas
    Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore.
    It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at
    https://forum.odroid.com/viewtopic.php?t=30303
    Maybe you can give it a try on Nano Pi M4v2.
     
    We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.
  12. Like
    Pedro Lamas reacted to piter75 in NanoPi M4V2 randomly crashes   
    Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them.
     
    cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters
     
  13. Like
    Pedro Lamas got a reaction from Werner in NanoPi M4V2 randomly crashes   
    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  
  14. Like
    Pedro Lamas got a reaction from RussianNeuroMancer in NanoPi M4V2 armbian-config is missing "hardware" entry   
    FYI, I found that this was due to a missing entry in debian-config-functions so I submitted a PR to add it (here) and this has now been merged so it should be available on the next update of armbian-config!
  15. Like
    Pedro Lamas reacted to Werner in NanoPi M4V2 armbian-config is missing "hardware" entry   
    Thx for the PR.
     
    You can also things like blacklisting the wifi module, using iwconfig wlan0 power off ...