Bug 7060

Summary: Thinkpad X60 stuck at low speed without battery
Product: ACPI Reporter: Zoltan Hidvegi (kernel.org)
Component: Power-ProcessorAssignee: Shaohua (shaohua.li)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, gsalgado, gustavodn, lenb, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.18-rc4 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Do not return true for osi=Windows

Description Zoltan Hidvegi 2006-08-26 16:49:54 UTC 
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.
Comment 1 Guilherme Salgado 2006-12-12 03:37:57 UTC 
I can reproduce this on a Thinkpad T60 Core Duo 1.66GHz, running a 2.6.17 kernel
from Ubuntu 6.10.
Comment 2 Thomas Renninger 2006-12-12 04:51:59 UTC 
Maybe the patch recently posted on the cpufreq list by Bruno Ducrot helps?:
allow the highest frequency if bios think so
Comment 3 Guilherme Salgado 2006-12-13 06:16:32 UTC 
No luck; still have the same problem on my 2.6.17 kernel with that path applied.
Comment 4 Guilherme Salgado 2007-01-18 17:24:13 UTC 
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.
Comment 5 Luming Yu 2007-01-18 18:02:17 UTC 
Does windows work?
Comment 6 Guilherme Salgado 2007-01-18 18:48:27 UTC 
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!)
Comment 7 Alexey Starikovskiy 2007-01-19 01:01:08 UTC 
Please try patch mentioned here: http://lkml.org/lkml/2007/1/16/120
Comment 8 Guilherme Salgado 2007-01-19 04:12:16 UTC 
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.
Comment 9 Natalie Protasevich 2007-06-14 17:40:12 UTC 
Are there any updates on this issue?
Thanks.
Comment 10 Guilherme Salgado 2007-06-14 18:15:46 UTC 
Isn't it clear that this is a BIOS bug?
Comment 11 Natalie Protasevich 2007-06-14 18:27:16 UTC 
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?
Comment 12 Guilherme Salgado 2007-06-14 19:30:28 UTC 
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.
Comment 13 Shaohua 2007-06-15 01:44:15 UTC 
It appears I can't reproduce the issue in my x60. It has 2.08 version BIOS, could you please check the latest BIOS?
Comment 14 Zoltan Hidvegi 2007-06-15 18:01:11 UTC 
> 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)
Comment 15 Guilherme Salgado 2007-06-17 17:15:25 UTC 
The problem is still present on a T60 with the latest (2.13) BIOS, though.
Comment 16 Gustavo De Nardin (spuk) 2008-04-24 07:03:29 UTC 
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".
Comment 17 Thomas Renninger 2008-07-10 09:10:13 UTC 
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.
Comment 18 Gustavo De Nardin (spuk) 2008-10-19 22:16:30 UTC 
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...