Bug 223816 - Kernel locks cpufreq at minimum when booting on battery power
Kernel locks cpufreq at minimum when booting on battery power
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-22 11:55 EST by George Dunlap
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.19-1.2895.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-30 11:43:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description George Dunlap 2007-01-22 11:55:07 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
plugged in.

Version-Release number of selected component (if applicable):
All so far

How reproducible:
100%

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
governor.
  
Actual results:
The cpu frequency stays locked at the minimum frequency.

Expected results:
The governor and the cpufreq applet should be able to increase the CPU frequency
to max, even while running on battery power.

Additional info:
According to Len Brown's presentation at the 2006 Linux Symposium
(http://www.linuxsymposium.org/2006/view_abstract.php?content_key=140), lowering
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.)
Comment 1 Jarod Wilson 2007-01-22 15:05:53 EST
This sounds at least somewhat similar to bug 188453...

If you would, please grab the kernel here:

http://people.redhat.com/jwilson/test_kernels/bz188453/

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.
Comment 2 George Dunlap 2007-01-22 15:56:44 EST
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
anything... :-)
Comment 3 George Dunlap 2007-01-22 16:00:43 EST
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.
Comment 4 Jarod Wilson 2007-01-22 16:11:27 EST
(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
things down...

(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.

No problem.
Comment 5 George Dunlap 2007-01-24 19:05:19 EST
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!
Comment 6 Jarod Wilson 2007-01-25 11:38:44 EST
Huh, no, not my doing, but I'm going to go poke at the diffs to see if I can
find an explanation... :)
Comment 7 Jarod Wilson 2007-01-30 11:43:41 EST
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.

Note You need to log in before you can comment on or make changes to this bug.