Red Hat Bugzilla – Bug 223816
Kernel locks cpufreq at minimum when booting on battery power
Last modified: 2007-11-30 17:11:53 EST
Description of problem:
If FC6 boots with the power unplugged, the cpu frequency for the Intel SpeedStep
is locked at the minimum. This cannot be overridden by the user-space cpufreq
applet, and continues locked at the minimum even after the power has been
Version-Release number of selected component (if applicable):
All so far
Steps to Reproduce:
1. Boot a laptop on battery power.
2. Start a gnome cpufreq applset and try to change the cpu frequency, or the
The cpu frequency stays locked at the minimum frequency.
The governor and the cpufreq applet should be able to increase the CPU frequency
to max, even while running on battery power.
According to Len Brown's presentation at the 2006 Linux Symposium
the CPU frequency does *not* increase battery efficiency. Assuming that the
same number of instructions are executed, the CPU used exactly the same amount
of power, but because other components (like the disk and screen) are running
for longer the overall effect is to reduce power efficiency. CPU throttling in
a laptop is primarily useful to control overheating. So the ideal thing for
laptop battery life would be to use the "performance" governor w/ the cpufreq
maxed out all the time.
(Voltage scaling, if available, would enable an increase in battery efficiency.)
This sounds at least somewhat similar to bug 188453...
If you would, please grab the kernel here:
Install it, boot it w/cpufreq.debug=7 added to your kernel boot params, then
collect dmesg output and attach it to this bug. Should help give a better
indication of where we're getting tripped up and locked at the minimum speed.
When I booted with the 2869.bz188453 kernel, I couldn't reproduce the problem.
I booted from the battery, but the cpufreq went up to full when I set the
governor to "performance". The problem is still there when I use the standard
2869 kernel. Were there any other changes, besides the extra printks? Heck, I
can try cpufreq.debuglevel=7 on the standard 2869 kernel, to see if that changes
I don't know if this helps, but when I use the 'hibernate' feature to do
software suspend, suspending it on A/C but restoring it on battery power, the
results are interesting:
CPU 0 will go to its max (2 GHz)
CPU 1 is locked at its min (1 GHz)
Thx for your help, btw.
(In reply to comment #2)
> When I booted with the 2869.bz188453 kernel, I couldn't reproduce the problem.
> I booted from the battery, but the cpufreq went up to full when I set the
> governor to "performance". The problem is still there when I use the standard
> 2869 kernel. Were there any other changes, besides the extra printks?
Nope, nothing but a few strategically-placed additional dprintks...
> Heck, I
> can try cpufreq.debuglevel=7 on the standard 2869 kernel, to see if that
> changes anything... :-)
Worth a shot. I suppose there could be some sort of race, and the dprintk's slow
(In reply to comment #3)
> I don't know if this helps, but when I use the 'hibernate' feature to do
> software suspend, suspending it on A/C but restoring it on battery power, the
> results are interesting:
> CPU 0 will go to its max (2 GHz)
> CPU 1 is locked at its min (1 GHz)
Odd. Forgot to ask... What model laptop is this, and what cpu(s)?
> Thx for your help, btw.
When the new kernel came out (2.6.19-1.2895), the problems seem to have been
fixed. Don't know if that was your doing or not, but thanks for your help anyway!
Huh, no, not my doing, but I'm going to go poke at the diffs to see if I can
find an explanation... :)
No major changes that I can easily identify as being the source of the fix, but
I'm still trying to understand all the code. Just the same, I'll go ahead and
close this bug out.