[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1038981: marked as done (capping maximum frequency no longer works in kernel 6.1)



Your message dated Thu, 01 May 2025 17:31:30 +0200 (CEST)
with message-id <20250501153130.641EABE2DE0@eldamar.lan>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #1038981,
regarding capping maximum frequency no longer works in kernel 6.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1038981: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038981
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-6.1.0-9-amd64
Version: 6.1.27-1

Below, I try to cap the frequency for each of my processor cores, but some cores resists:

# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq && cat /sys/devices/system/cpu/cpu$i/cpufreq/scaling_cur_freq; done
400002
400004
399989
2300000
2300000
2300000
400013
399519

Moreover, the cores that resist changes each time; e.g., the next run yields this:

# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq && cat /sys/devices/system/cpu/cpu$i/cpufreq/scaling_cur_freq; done
400024
2300000
400002
400020
2300000
400000
399930
400008

I tried to read the frequency via /proc/cpuinfo:

# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done && cat /proc/cpuinfo | grep MHz
cpu MHz : 400.001
cpu MHz : 399.989
cpu MHz : 2300.000
cpu MHz : 400.107
cpu MHz : 1028.210
cpu MHz : 399.942
cpu MHz : 400.001
cpu MHz : 400.004

I also tried to use tlp (yes, I said TLP_DEFAULT_MODE=BAT, TLP_PERSISTENT_DEFAULT=1, CPU_BOOST_ON_BAT=0, and CPU_HWP_DYN_BOOST_ON_BAT=0) and sysfs packages; all methods yield the similar results: capping the frequency of all cores doesn't work. I tried to cap all at, say, 800 MHz, 1.2 GHz, and 2 GHz instead, but the result is often (but not always!) the same: a few cores often (but not always!) resist and run at higher frequencies up to 2.4 GHz. Only seldom I see the expected:

# for i in `seq 0 7`; do echo "400000"> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done && cat /proc/cpuinfo | grep MHz
cpu MHz : 400.004
cpu MHz : 399.988
cpu MHz : 399.999
cpu MHz : 400.011
cpu MHz : 399.980
cpu MHz : 400.048
cpu MHz : 400.002
cpu MHz : 400.008

But running cat /proc/cpuinfo | grep MHz a few seconds later yields again a few lines with 2300.000.

The governor is powersave everywhere.

For kernel 5 with Debian 11 (which I can no longer test), everything worked like a charm (or at least I always observed all-400-MHz back then). So either the new kernel is erroneous or my processor broke somehow (perhaps, during the upgrade). It has Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz.

Who is the culprit? What to do?

Gratefully,
AlMa

--- End Message ---
--- Begin Message ---
Hi

This bug was filed for a (very) old kernel or the bug is old itself
without resolution. Maybe it was for a feature enablement which nobody
acted on. We are sorry we were not able to timely deal with this issue.
There are many open bugs for the src:linux package and thus we are
closing older bugs where it's unclear if they still occur in newer
versions and are still relevant to the reporter. For an overview see:
https://bugs.debian.org/src:linux .

If you can reproduce your issue with

- the current version in unstable/testing
- the latest kernel from backports

or, if it was a feature addition/wishlist and still consider it
relevant, then:

Please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Please try to provide as much fresh details including kernel logs where
relevant. In particular were an issue is coupled with specific hardware we
might ask you to do additional debugging on your side as the owner of the
hardware.

Regards,
Salvatore

--- End Message ---

Reply to: