Creating a bug report/issue
Required Information
DietPi version |
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=27
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
Distro version | buster 10.2
Kernel version |
Linux DietPi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
SBC device | RPi 4 Model B (armv7l)
Power supply used | 3A Official
SDcard used | SanDisk ultra
Extra details
My CPU is locked at 600 MHz with Governor powersave.



I updated EEPROM after updating to DietPi 6.27.2; maybe related?

[EDIT]
-rwxr-xr-x 1 root root 12K Jan 2 04:17 dietpi.txt
hi,
as far as I can see some coding changed in /DietPi/dietpi/func/dietpi-set_cpu with new version v6.27.2. So I guess it has noting to do with the EEPROM update and might be a typo/bug in the scripting.
@MichaIng
I guess in section Apply_CPU_Gov the following needs to be changed, line 75. But might be I'm wrong:
from
for i in /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_available_governors
to
for i in /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor
That did the trick, cheers!

On a tangent, is it supposed to be 1500 MHz when Governor is ondemand?
There is virtually no load.

it should go down after a while
Well maybe this it the culprit?
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.
It still hasn't gone down, did a reboot as well.

@bbsixzz
Indeed the script itself should raise the load for a tiny time which is enough to raise frequencies for 1 second (default before or goes down after load) on slower SBCs.
To check with less overhead:
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
If this is not available:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
Ref: https://www.kernel.org/doc/html/v4.19/admin-guide/pm/cpufreq.html#policy-interface-in-sysfs
cpuinfo_cur_freq result: 1500000
scaling_cur_freq result: 600000
I don't think it's a big deal, but it seems locked at 1500 MHz.
Is the RPi4 really so slow that the CPU script throttles all 4 cores like that?
[EDIT]

[EDIT]
I did a test using Governor conservative, I downloaded a large file using SFTP.

It throttled correctly during download and stepped down when idle.
It looks to me like Governor ondemand doesn't work correctly or the settings are bad.
Maybe these two paramaters need adjustment? They are not available for conservative.
Ondemand Sample Rate: [25ms]
Ondemand Down Factor: [80 (2000ms)]
I can run the CPU script all day on Governor conservative and it never throttles to 1500 MHz.
For me it looks like using ondemand will look me at 1500 MHz and it's not stepped down. CPU temp is below 40'C. So it's doing nothing.
root@DietPi4:~# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv7l
Temperature | 39'C : 102'F (Cool runnings)
Governor | ondemand
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 1500 MHz 600 MHz 1500 MHz
CPU1 | 1500 MHz 600 MHz 1500 MHz
CPU2 | 1500 MHz 600 MHz 1500 MHz
CPU3 | 1500 MHz 600 MHz 1500 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script,
due to the processing required to run it.
While using conservative seems working correctly. It's stepping up if needed and going down once done.
root@DietPi4:~# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv7l
Temperature | 50'C : 122'F (Running warm, but safe)
Governor | conservative
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 1500 MHz 600 MHz 1500 MHz
CPU1 | 1500 MHz 600 MHz 1500 MHz
CPU2 | 1500 MHz 600 MHz 1500 MHz
CPU3 | 1500 MHz 600 MHz 1500 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script,
due to the processing required to run it.
root@DietPi4:~#
root@DietPi4:~#
root@DietPi4:~#
root@DietPi4:~# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv7l
Temperature | 38'C : 100'F (Cool runnings)
Governor | conservative
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 600 MHz 600 MHz 1500 MHz
CPU1 | 600 MHz 600 MHz 1500 MHz
CPU2 | 600 MHz 600 MHz 1500 MHz
CPU3 | 600 MHz 600 MHz 1500 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script,
due to the processing required to run it.
I used dietpi-config: Stress Test to simulate the load.
[EDIT]
Same seems to be valid for my RPi 3 Model B+ running v6.26.3
Nevermind, the fix above did work I just had a typo.
@MichaIng just to be clear, you should investigate ondemand as it doesn't seem to be working.
The original bug of "permission denied" is however fixed.
@bbsixzz
I am pretty sure that it works fine. Please check the following:
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
It should show you how long (for current session) the CPU was in which state (only the two 600 and 1500 on RPi).
You can raise the CPU usage on which the freq is raised via up_treshold:
cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Its 50% by default on DietPi. When raising to e.g. 95% it might stay on lower freq during the commands.
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
Or via dietpi-config to be persistent.
Alright, after a reboot I got the following numbers which indicate everything works fine!
600000 3509
1500000 5709
Thank you for the education :]
v6.28 is out, I mark this issue as closed.
Most helpful comment
hi,
as far as I can see some coding changed in
/DietPi/dietpi/func/dietpi-set_cpuwith new version v6.27.2. So I guess it has noting to do with the EEPROM update and might be a typo/bug in the scripting.@MichaIng
I guess in section
Apply_CPU_Govthe following needs to be changed, line 75. But might be I'm wrong:from
to