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.)
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.
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... :-)
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 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.
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.