Raspberry Pi | CPU frequency scaling does not work

[ayo-x]

Creating a bug report/issue

Required Information

• DietPi version |
  G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=9
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='applied'
G_LIVE_PATCH_STATUS[1]='not applicable'
G_LIVE_PATCH_STATUS[2]='not applicable'

• Distro version | bullseye 0

• Kernel version | Linux DietPi 5.10.63-v7l+ #1488 SMP Thu Nov 18 16:15:28 GMT 2021 armv7l GNU/Linux

• SBC model | RPi 4 Model B (armv7l)

• Power supply used | 5.1V 3A

• SDcard used | SanDisk ultra 32GB / Kingston 32GB (testing)

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi?
  Yes.

Steps to reproduce

1. We'll do a clean install of DietPi armv7 image.
2. Go through the initial setup process, without installing additional software.
3. Reboot.
4. After booting back up, we'll wait ~20s for the initial_turbo to pass.
5. Check CPU frequencies with either cpu or cat /sys/devices/system/cpu/cpufreq/policy0/{scaling_min_freq,scaling_cur_freq}.
6. Going into dietpi-config / Performance options / Overclocking & CPU Governor and choose any combo of OC profile and governor. Reboot.
7. After booting and initial_turbo passing, we'll check CPU frequencies again.

Expected behaviour

• Since there's no software besides the Os running, CPU frequency should be at/near base value.

Actual behaviour

• Dynamic CPU scaling isn't working properly. The minimum frequency is always equal to the maximum frequency.

Extra details

• On Raspberry Pi OS lite, the CPU scales normally. Between 600 and 1500 MHz.
• Setting the initial_turbo to 0 doesn't change anything regardin scaling.

Below are results using a few OC profile and governor combos.
energy-saving + powersave

cpu
Architecture | armv7l
Temperature | 37 °C / 98 °F : Cool runnings
Governor | powersave

             Current Freq    Min Freq   Max Freq

CPU0 | 1500 MHz 1500 MHz 1500 MHz
CPU1 | 1500 MHz 1500 MHz 1500 MHz
CPU2 | 1500 MHz 1500 MHz 1500 MHz
CPU3 | 1500 MHz 1500 MHz 1500 MHz

cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_min_freq,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
powersave
1500000
1500000
1500000
1500000 161598

───────────────────────────────────────────────────────────────────
default + schedutil

cpu
Temperature | 37 °C / 98 °F : Cool runnings
Governor | schedutil

             Current Freq    Min Freq   Max Freq

CPU0 | 1500 MHz 1500 MHz 1500 MHz
CPU1 | 1500 MHz 1500 MHz 1500 MHz
CPU2 | 1500 MHz 1500 MHz 1500 MHz
CPU3 | 1500 MHz 1500 MHz 1500 MHz

cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_min_freq,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
schedutil
1500000
1500000
1500000
1500000 18048

────────────────────────────────────────────────────────────────────
medium ARM + ondemand

cpu
Architecture | armv7l
Temperature | 37 °C / 98 °F : Cool runnings
Governor | ondemand
Throttle up | 50% CPU usage

             Current Freq    Min Freq   Max Freq

CPU0 | 1800 MHz 1800 MHz 1800 MHz
CPU1 | 1800 MHz 1800 MHz 1800 MHz
CPU2 | 1800 MHz 1800 MHz 1800 MHz
CPU3 | 1800 MHz 1800 MHz 1800 MHz

cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_min_freq,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
ondemand
1800000
1800000
1800000
1800000 8327

─────────────────────────────────────────────────────────────────────
high ARM + conservative

cpu
Architecture | armv7l
Temperature | 41 °C / 105 °F : Optimal temperature
Governor | conservative
Throttle up | 50% CPU usage

             Current Freq    Min Freq   Max Freq

CPU0 | 1900 MHz 1900 MHz 1900 MHz
CPU1 | 1900 MHz 1900 MHz 1900 MHz
CPU2 | 1900 MHz 1900 MHz 1900 MHz
CPU3 | 1900 MHz 1900 MHz 1900 MHz

cat /sys/devices/system/cpu/cpufreq/policy0/{affected_cpus,scaling_governor,scaling_min_freq,scaling_cur_freq,cpuinfo_cur_freq,stats/time_in_state}
0 1 2 3
conservative
1900000
1900000
1900000
1900000 12898

[MichaIng]

Many thanks for your report.

Can you show the content of your config.txt:

cat /boot/config.txt

[ayo-x]

root@DietPi:~# cat /boot/config.txt

# Docs: https://github.com/raspberrypi/documentation/tree/develop/documentation/asciidoc/computers/config_txt
# Overlays: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

#-------Display---------
# Max allocated framebuffers: Set to "0" in headless mode to reduce memory usage
# - Defaults to "2" on RPi4 and "1" on earlier RPi models
#max_framebuffers=0

# If you get no picture, set the following to "1" to apply most compatible HDMI settings.
#hdmi_safe=1

# Uncomment to adjust the HDMI signal strength if you have interferences, blanking, or no display.
# - Values from "0" to "11" are allowed, use values above "7" only if required, e.g. with very long HDMI cable.
# - Default on first RPi1 A/B is "2", else "5", on RPi4 this setting is ignored.
#config_hdmi_boost=5

# Uncomment if HDMI display is not detected and composite is being outputted.
#hdmi_force_hotplug=1

# Uncomment to disable HDMI even if plugged, e.g. to force composite output.
#hdmi_ignore_hotplug=1

# Uncomment to force a console size. By default it will be display's size minus overscan.
#framebuffer_width=1280
#framebuffer_height=720

# Uncomment to enable SDTV/composite output on RPi4. This has no effect on previous RPi models.
#enable_tvout=1
# SDTV mode
#sdtv_mode=0

# Uncomment to force a specific HDMI mode (this will force VGA).
#hdmi_group=1
#hdmi_mode=1

# Uncomment to force an HDMI mode rather than DVI. This can make audio work in DMT (computer monitor) modes.
#hdmi_drive=2

# Set "hdmi_blanking=1" to allow the display going into standby after 10 minutes without input.
# With default value "0", the display shows a blank screen instead, but will not go into standby.
# NB: With "1" some applications (e.g. Kodi, OMXPlayer) cannot prevent display standby due to missing DPMS signal.
#hdmi_blanking=1

# Set to "1" if your display has a black border of unused pixels visible.
disable_overscan=1

# Uncomment the following to adjust overscan. Use positive numbers if console goes off screen, and negative if there is too much border.
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# Rotation
#display_hdmi_rotate=0
#lcd_rotate=0

#-------RPi camera module-------
#start_x=1
#disable_camera_led=1

#-------GPU memory splits-------
gpu_mem_256=16
gpu_mem_512=16
gpu_mem_1024=16

#-------Boot splash screen------
disable_splash=1

#-------Onboard sound-----------
dtparam=audio=off

#-------I2C-------------
#dtparam=i2c_arm=off
#dtparam=i2c_arm_baudrate=100000

#-------SPI-------------
#dtparam=spi=off

#-------Serial/UART-----
# NB: "enable_uart=1" will forcefully set "core_freq=250" on RPi models with onboard WiFi, unless "force_turbo=1" is set.
enable_uart=1

#-------SD card HPD-----
# Comment to enable SD card hot-plug detection, while booting via USB or network.
# NB: This causes constant CPU load and kernel errors when no SD card is inserted.
dtparam=sd_poll_once

#-------Overclock-------
temp_limit=75
initial_turbo=20

#over_voltage=0
#arm_freq=1500
#core_freq=500

#over_voltage_min=0
#arm_freq_min=300
#core_freq_min=250
#sdram_freq_min=400
dtoverlay=dietpi-disable_vcsm

[MichaIng]

It is not very likely on RPi 4, but in theory some running processes or the commands to check the CPU frequency themselves could cause maxing them out. Can you check htop about the CPU usage, and in case which process causes it?

And to check the actual time in pstates you can check:

cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state

Although that powersave also does not lower the frequency proves that something isn't in order since this should lead to 600 MHz constantly (after initial_turbo). Disabling initial_turbo (you can also remove or comment it in config.txt) doesn't change something, right? There was a bug in the past where it indeed broke down scaling, but that was fixed a long time ago: raspberrypi/firmware#1005
With current kernel it works fine here on my RPi models.

[ayo-x]

I've been checking CPU frequency on Raspberry OS with the same commands and, even if I spammed these commands in the terminal, the frequencies shown were 6-700 MHz.

cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
1500000 36172

I've read about that bug regarding initial_turbo , that's why I also tested with it disabled.
htop bearly shows any CPU usage.

[whyisthisbroken]

Hi, same weird problem here.
i do a clean install of DietPi armv8 image on a RPI 4B and got the same problem.
Min and Max Freq are the same and dont throttle down... directly after finish the DietPi installation.

EDIT:
So, i flashed an old Version from Dietpi (7.4.2) on my SD and start the installation on my RPI, after the installation process and the automatic update to the last version 7.9.3 my frequencies are correctly again.

so i think that in the new 7.9.3 version is something wrong with the installation process.

Sorry for my bad english... i hope its understandable...

[MichaIng]

Okay so we have it on an ARMv7 image and on an ARMv8 image, hence not architecture related.

Strange, my RPi 2 is not affected, it scales as expected between 600 and 900 MHz, but my RPi Zero W is, which runs even on latest master firmware 5.10.85+ #1501, so that issue was not yet fixed. The problem is not the CPU governor, but the firmware itself which reports only one (the highest) available scaling frequency:

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
1100000

This matches you cpu output where current, min and max frequencies all show the same value.

Needs to be reported upstream.

[MichaIng]

Reported: raspberrypi/firmware#1669

[MichaIng]

@whyisthisbroken

So, i flashed an old Version from Dietpi (7.4.2) on my SD and start the installation on my RPI, after the installation process and the automatic update to the last version 7.9.3 my frequencies are correctly again.

That shouldn't be possible, the new image is the old image with updated packages and should match the updated one nearly 100%, at least regarding all that is relevant here. Did you do a reboot after the update and checked back?

[whyisthisbroken]

@whyisthisbroken

So, i flashed an old Version from Dietpi (7.4.2) on my SD and start the installation on my RPI, after the installation process and the automatic update to the last version 7.9.3 my frequencies are correctly again.

That shouldn't be possible, the new image is the old image with updated packages and should match the updated one nearly 100%, at least regarding all that is relevant here. Did you do a reboot after the update and checked back?

Yep, rebooted many time cause I installed many services to complete my setup again. (Kodi, Adguard Home etc)

I checked and it works. It's strange I know but this was the only solution for me 😅

[MichaIng]

Mysterious. I'm currently downgrading the kernel on RPi Zero, which was setup long before I updated our images the last time, so the specific image build cannot be the reason.

EDIT: Issue persists, even when commenting all config.txt settings.

[MichaIng]

@whyisthisbroken @ayo-x
It seems the force_turbo bit is set, even that it is not set. Can you check (using the affected image):

vcgencmd get_config force_turbo
grep force_turbo /boot/config.txt

[MichaIng]

Found it, it is a changed comment (!) in config.txt which is falsely somehow used as effective config to enable force_turbo=1: raspberrypi/firmware#1669 (comment)

My goodness, I hope this did not void warranties for anyone. Will quickly redo the images and ship a live patch to remove that comment from all systems.

Just to how how much this is a bug, here is the change in the comment, just a little wording change, which causes/solves the issue: a1d1cee
Since this was with v7.8, the older image has still the old comment and as such does not suffer from this.

[MichaIng]

Quick fix:

sed -i '/^[[:blank:]]*#.*force_turbo=1/d' /boot/config.txt
reboot

[MichaIng]

Fixed for new images with: 934459f

[MichaIng]

A live patch has just been merged: #5091
Applying this via dietpi-update and doing a reboot will solve the issue, along with other potential parser issues as it truncates all comment lines to max 100 characters.

Background: The RPi config.txt parser obviously internally applies a line break at column/character 100, and by very lucky change this commit aligned the text containing force_turbo=1 to start exactly at column 100, so that it became an effective setting. Just one character left or right solves it/wouldn't have caused it 😞. As a result, any line with more than 100 characters is a potential issue, so I reduced/capped the lengths in our default config and the live patch simply truncates all lines after column 99.

[whyisthisbroken]

Thx for the quick solution 👍
Great support as always 💪

[MichaIng]

Thanks back for reporting this, to both of you. I would have overseen it, while it is quite an important one. In case of high over_voltage (AFAIK over_voltage=7 and higher) with forced turbo warranty would be void. I'm still shocked how we could have been so unlucky to not only align a setting exactly to character 100 in a comment, and then literally the most critical setting of all of them, with which one can void warranty and damage the hardware (not alone with it, but it is kind of an unlock) 😕.

[ayo-x]

I'm still shocked how we could have been so unlucky to not only align a setting exactly to character 100 in a comment, and then literally the most critical setting of all of them

🤯 Wow..

I'm really glad you found where the actual problem was. Thank you for your time looking into this.

[MichaIng]

I'll mark this as closed. Fixed for v8.0 and config.txt backported to v7.9 + live patch + all RPi images recreated.

[Joulinar]

@MichaIng
can you have a look to this forum post. A user with issues after applying the patch https://dietpi.com/phpbb/viewtopic.php?t=9812

[MichaIng]

Luckily unrelated.