[RPi 4B] Kernel 6.12.62 causes CPU frequency stuck at 1000-1400 MHz with schedutil governor

[Laurent-Jongbeys]

Describe the bug

After upgrading from kernel 6.12.47 to 6.12.62 via apt update, the CPU frequency remains stuck at 1000-1400 MHz even when idle, instead of dropping to 600 MHz. The schedutil governor appears unable to scale down properly.

Rolling back to kernel 6.12.47 via Restic backup immediately resolved the issue - CPU now correctly idles at 600 MHz.

Expected behaviour:
CPU frequency should drop to 600000 (600 MHz) at idle with schedutil governor.

Actual behaviour:
CPU frequency stays around 1000000-1400000 (1000-1400 MHz) at idle, never dropping to minimum frequency. This persists regardless of load or wait time.

Steps to reproduce the behaviour

1. Start with kernel 6.12.47+rpt-rpi-v8 (working correctly)
2. Run apt update && apt upgrade (kernel upgrades to 6.12.62)
3. Reboot
4. Wait 10+ seconds with no activity
5. Check frequency: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Device (s)

Raspberry Pi 4 Mod. B

System

• Model: Raspberry Pi 4 Model B
• OS: DietPi v9.16.3
• Problematic kernel: 6.12.62+rpt-rpi-v8
• Working kernel: 6.12.47+rpt-rpi-v8
• Governor: schedutil (DietPi default)
• Architecture: aarch64

Logs

With kernel 6.12.62 (broken):

$ uname -r
6.12.62+rpt-rpi-v8

$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
schedutil
schedutil
schedutil
schedutil

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
600000

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
1800000

# After 10+ seconds idle:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1000000  # (or ~1400000, varies but never 600000)

$ uptime
load average: 0.08, 0.05, 0.01  # Near idle, minimal background services

With kernel 6.12.47 (working):

$ uname -r
6.12.47+rpt-rpi-v8

# After 10 seconds idle:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
600000  # Correctly at minimum

Workaround

1. Rollback to a backup containing kernel 6.12.47
2. Block kernel updates: sudo apt-mark hold linux-image-rpi-v8

Additional context

• Tested with ondemand governor as well - same issue
• No throttling reported (vcgencmd get_throttled returns 0x0)
• Temperature normal (~45°C)
• Services running: Pi-hole, Navidrome, Jellyfin, Nginx, Uptime Kuma (same services on both kernels)
• The system was near idle during testing (load average < 0.1, minimal background services)

[popcornmix]

I'm only seeing this with schedutil - not ondemand:

pi@dompi4:~ $ tail -1 /proc/cpuinfo
Model		: Raspberry Pi 4 Model B Rev 1.4
pi@dompi4:~ $ uname -a
Linux dompi4 6.12.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1 (2025-12-18) aarch64 GNU/Linux
pi@dompi4:~ $ echo schedutil | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil
pi@dompi4:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1200000
pi@dompi4:~ $ echo ondemand | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
pi@dompi4:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
600000

[jan-krieg]

You could check the output of cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state; that gives you the amount of time spent at each frequency.

The problem with using cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq or similar manual measurement is that you disturb the system by running the command, which makes it unreliable.

So while it's of course possible that there's a bug in 6.12.62 that prevents dropping to lowest frequency with schedutil, it's unclear from your observations whether the system does or does not properly drop to 600 MHz at idle.

On my system (RPi 4B, gentoo, kernel 6.6.47, schedutil governor) I also almost always get 1000 MHz while idle when checking the current frequency via cat scaling_cur_freq. However, cat time_in_state shows that the system actually spends most of its time at 600 MHz as it should:

# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
600000 1508188
700000 20771
800000 23064
900000 15850
1000000 18392
1100000 16418
1200000 14580
1300000 10752
1400000 10855
1500000 228039

Furthermore, checking cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table shows that when at 600 MHz, the transition to 1000 MHz is the second-most frequent one (with by far most frequent being a direct jump to maximum frequency),

# cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table
   From  :    To
         :    600000    700000    800000    900000   1000000   1100000   1200000   1300000   1400000   1500000
   600000:         0      7199      2103      1063      4316       871       984       319       184     41991
   700000:      8307         0      2923       723       658       335       142        70        44       499
   800000:      2986      3320         0      2415      1240       427       206       112        73       629
   900000:      1257      1377      3107         0      1952       887       245       193        97       473
  1000000:      1663       599      1457      2667         0      4345      1850       408       308      1628
  1100000:      1288       282       585      1163      2363         0      4988      1330       378      1157
  1200000:       829       246       229       462      1802      2909         0      3215      1052      1629
  1300000:       364        95       140       214       530      1205      1329         0      3038      2056
  1400000:       182        52        79       124       340       817      1148      1337         0      5039
  1500000:     42153       531       785       757      1725      1738      1481      1987      3944         0

suggesting that maybe cat scaling_cur_freq (and other processes that only result in very brief & low load) causes a frequency increase to 1000 MHz that masks the previous idle state at 600 MHz.

One can do a naive check how simply shell commands influence the frequency with the following:

#!/bin/bash
pre=$(cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table)
sleep 0.1
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
post=$(cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table)
git --no-pager diff --color --word-diff <(echo "$pre") <(echo "$post")

The output naturally fluctuates across runs, but based on a few sample runs on my idle system, it usually looks similar to the following:

1000000
diff --git a/dev/fd/63 b/dev/fd/62
--- a/dev/fd/63
+++ b/dev/fd/62
@@ -1,11 +1,11 @@
   From  :    To
         :    600000    700000    800000    900000   1000000   1100000   1200000   1300000   1400000   1500000
   600000:         0      7275      2177      1098      [-4586-]{+4587+}       900      1018       334       186     44996
   700000:      8456         0      2967       735       675       343       143        70        44       508
   800000:      [-3080-]{+3081+}      3377         0      2468      1289       436       208       113        75       633
   900000:      1296      1417      [-3183-]{+3184+}         0      2020       915       247       196        97       484
  1000000:      1770       628      1488      2773         0      [-4564-]{+4565+}      1919       427       313      1657
  1100000:      1364       292       596      [-1187-]{+1188+}      2443         0      5206      1393       382      1185
  1200000:       876       256       237       471      1855      3015         0      3327      1085      1665
  1300000:       384        99       143       218       540      1242      1356         0      3148      2101
  1400000:       190        53        80       125       348       842      1168      1351         0      5178

While this doesn't show the start & end frequency, it is equivalent to a circular permutation of the following frequency progression:
1000 MHz -> 1100 MHz -> 900 MHz -> 800 MHz -> 600 MHz -> 1000 MHz
Which seems consistent with the assumption that running cat scaling_cur_freq and similar commands results in a sufficiently fast frequency boost that it disturbs the measurement.

[Laurent-Jongbeys]

Thanks for the detailed explanation about time_in_state and measurement artifacts.

However, I'd like to point out that the same measurement method (cat scaling_cur_freq) returned different results between kernels:

Kernel	cat scaling_cur_freq after 10s idle
6.12.47	600000 (600 MHz)
6.12.62	1000000-1400000 (1000-1400 MHz)

Even if reading scaling_cur_freq disturbs the system, this disturbance should be consistent across kernel versions — unless I'm missing something.

I'm not an expert on kernel internals, but my understanding is that userspace tools (cat, shell) are unchanged between kernel versions, so the CPU load generated by the measurement should be similar. If the results differ, something may have changed in how schedutil or the cpufreq subsystem responds to that load. But I could be wrong on this.

I've since rolled back to 6.12.47 and blocked kernel updates, so I cannot easily collect time_in_state comparisons without re-upgrading.

[jan-krieg]

Yes fully agreed that it's not obvious why there should be such difference in results with cat scaling_cur_freq when only switching between different kernel patch versions.

My point is simply that using such measurement, one cannot distinguish whether the CPU is stuck at higher frequencies at idle or not. As mentioned, cat scaling_cur_freq almost always returns 1000 MHz on my device when run at idle, even though the CPU correctly idles at 600 MHz.

Maybe there was a minor change in the kernel that affects how quickly the governor ramps up in some cases (and hence incidentally affecting the output of cat scaling_cur_freq)? Or RPi team made a change in the kernel config across these two kernel patch releases that causes this? Would be interesting to know, but may in the end be quite irrelevant in practice unless there's some problematic behaviour caused by the change such as not properly scaling down at idle (which as outlined would need different measurement to detect).