Most recent kernel where this bug did not occur: Distribution: Debian unstable Hardware Environment: Thinkpad X60 Core Duo 1.83GHz Software Environment: speedstep-centrino Problem Description: CPU speed cannot be increased when the battery is not present. Steps to reproduce: Using ondemand governor, frequency scaling works as expected when the battery is in the system, both with A/C plugged in or unplugged. When the bettery is removed, if the CPU is busy, it keeps running at 1.83GHz, /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq shows 1833000. When the busy job quits, the CPU drops back to 1GHz and /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq also changes to 1000000 and can no longer be increased. After reinserting the battery, /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq accepts larger frequencies again. When using the performance governor, the speed drops immediately uppon removing the battery. Thinkpad has the latest (1.06) BIOS. This happens even is the battery ACPI module is not loaded.
I can reproduce this on a Thinkpad T60 Core Duo 1.66GHz, running a 2.6.17 kernel from Ubuntu 6.10.
Maybe the patch recently posted on the cpufreq list by Bruno Ducrot helps?: allow the highest frequency if bios think so
No luck; still have the same problem on my 2.6.17 kernel with that path applied.
After some time debugging/cowboying a 2.6.20-rc5 tree, I found that the kernel is just doing what the BIOS tells it to do, so this is certainly a BIOS issue. The issue is that once the battery is removed, the BIOS gives the kernel a _PPC of 2, which means that the kernel is only allowed to use the states from 2 to 2, even though the possible states are from 0 to 2. Of course, state=0 means that any frequency, up to the highest possible can be used, while state=2 means that (in our case) only the lowest frequency can be used. I'll try to hack my BIOS' DSDT now. Will comment here if I get it to work, since it may be useful to somebody else.
Does windows work?
No. As I expected, got exactly the same behaviour on windows. (I knew one day I'd be thankful for not erasing the windows partition!)
Please try patch mentioned here: http://lkml.org/lkml/2007/1/16/120
I've already tried it, and it doesn't solve this problem. To solve this problem I could simply remove a call to acpi_processor_get_platform_limit(pr) from acpi_processor_ppc_has_changed, since that's the function responsible for obtaining the value of _PPC (and storing it in pr->performance_platform_limit) from the BIOS, but that doesn't look right to me. There are also other possible ways to workaround this problem in the kernel, but that may cause regressions. What I think is that the BIOS shouldn't notify the kernel that the _PPC has changed when the battery is removed, since in that case we certainly have AC plugged in.
Are there any updates on this issue? Thanks.
Isn't it clear that this is a BIOS bug?
Do we need any type of blacklisting etc. in the kernel or should we encourage people say to contact BIOS vendors and fix the bugs... Any suggestions?
In this case the "It works on windows, it must also work on Linux" argument is not valid since it doesn't work on windows either. I think we should be demanding a proper fix from BIOS vendors. It's something that doesn't work on windows and that fact is hopefully enough to convince them to fix their BIOSes.
It appears I can't reproduce the issue in my x60. It has 2.08 version BIOS, could you please check the latest BIOS?
> It appears I can't reproduce the issue in my x60. It has 2.08 version BIOS, > could you please check the latest BIOS? I can confirm this, I've upgraded to BIOS 2.11 EC version 1.13 and it can now run at full-speed without battery.(In reply to comment #13)
The problem is still present on a T60 with the latest (2.13) BIOS, though.
I have a T60, latest BIOS, frequently used without battery plugged. I was able to get CPU at full speed using kernel 2.6.22 in Mandriva Linux 2008.0. But with kernel 2.6.24 I couldn't anymore, so some regression happened. But now I am able to get full speed set with kernel 2.6.24, after changing, in the BIOS, "Config"->"Power"->"Intel Speedstep technology", "Mode for AC" set to "Maximum Performance" instead of the default "Automatic".
Created attachment 16791 [details] Do not return true for osi=Windows Can you give this patch a try, pls. Set acpi_osi=windows_false boot param or enable CONFIG_ACPI_OSI_SPEC_CONFORM in .config.
Tried the patch some time ago, I'm not sure it didn't work or I couldn't make it. Anyways, kernel 2.6.26 onwards works around the issue again...