Bug 10110

Created attachment 15000 [details]
Hex ACPI dump of T61 BIOS 2.09

Created attachment 15001 [details]
Binary ACPI dump of T61 BIOS 2.09, for testing/debugging

Will you please try the latest kernel(2.6.25-rc2) and confirm whether the problem can be avoided by the boot option of "processor.noppc"?
Thanks.

Will you please attach the output from the following commands?
     acpidump --addr 0x7d6e1b32 --length 0x2c4 -o cpu0ist
     acpidump --addr 0x7d6e1e7b --length 0x85e -o cpu0cst
Thanks.

Hi, Daniel
    Will you please enable the debug function of acpi and cpufreq in kernel configuration and try to boot the system with the option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x17 cpufreq.debug=7"?
   Please attach the output of dmesg.
   Thanks.

Correction to above information:

cpufreq-core: CPU 0: _PPC is 3 - frequency  limited
cpufreq-core: CPU 1: _PPC is 0 - frequency not limited

...is from booting with 'maxcpus=1'. Booting without maxcpus, we get:

cpufreq-core: CPU 0: _PPC is 3 - frequency  limited
cpufreq-core: CPU 1: _PPC is 3 - frequency  limited

Also, 'processor.noppc' is not recognised with 2.6.25-rc3, or is in the kernel sources.

Booting with 'processor.ignore_ppc' does unlock full performance, so is a good workaround for now. Perhaps we need a DMI blacklist for this?

Created attachment 15008 [details]
Output of 'dmesg' with kernel booted with requested debug options only

Created attachment 15009 [details]
Output from 'acpidump --addr 0x7d6e1b32 --length 0x2c4 -o cpu0ist'

Created attachment 15010 [details]
Output from 'acpidump --addr 0x7d6e1e7b --length 0x85e -o cpu0cst'

Could it be that _PPC is evaluated at init time again with the latest thermal changes?

Also see:
git commit e4233dec749a3519069d9390561b5636a75c7579

BTW: BIOS Version 2_09 is rather old. There were SATA native mode and USB specific Linux patches for Lenovo BIOSes recently which I expect you are missing.

It would also be interesting to know whether the lastest BIOS simply fixes this (without addtional patches)

It would also be interesting whether this gets fixed if the kernel does not respond true on all Windows versions for _OSI calls, ThinkPads seem to add hacks for all kind of Windows versions, that currently all return true on Linux.
Not sure whether they can all be switched off via boot param, maybe ykzhao knows, otherwise I can look at it and tell you how to test... This should get tested first, because it may be related to a specific BIOS, this would be really interesting to know (and explain why only some T61s are affected)

BIOS 2.09 was released 2007-12, so quite recent. I'll re-check with BIOS 2.10, released a few weeks ago, however this is unlikely to change anything:

http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-67989

Ok, then it is another machine model.
If you still have not updated BIOS or still see the bug, can you try:
acpi_osi=
boot parameter, just let it empty and try whether it helps, pls.

Booting with just 'acpi_osi=', we get as expected:

ACPI: DMI detected: Lenovo ThinkPad T61
ACPI: Added _OSI(Linux)
ACPI: _OSI method disabled

However, we're still limited:
# cat cpuinfo_max_freq
2201000
# cat scaling_max_freq
1200000

Hi, Daniel
    Will you please try the boot option of "processor.noppc" and see whether the scaling_max_freq is 1200000KHz?  ( The boot option of "acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug" is still required.)
    Please attach the output of dmesg and /sys/device/system/cpu/cpu0/cpufreq/scaling_max_freq.
    Thanks.

I attached a new dmesg output, booting with 'acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug=7 processor.ignore_ppc=1'.

The scaling_max_freq value is:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2201000

Created attachment 15025 [details]
acpi.debug_layer=0x1000000
dmesg from kernel booted with 'acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug=7 processor.ignore_ppc=1'

Hi, Daniel
Thanks for the info. From the log in comment #17 it seems that the boot option of "processor.ignore_ppc" can avoid the _PPC limit problem. 

At the same time there exists the message that the _PPC limit is 3 for cpu0. It looks very normal. According to acpi spec, the _PPC object is an optional method that dynamically indicates to OSPM the number of performance states currently supported by the platform. This method returns a number that indicates the _PSS entry number of the highest performance state.And it is used to limit the cpu working frequency. Because the _PPC limit is 3, the cpufreq will be limited to 1200000KHz.

Will you please upgrade the bios for your laptop and see whether the problem still exists?
Thanks.
 

Hi Yakui-san,

Minor correction to "_PPC limit is 3 for cpu0" - it is set to 3 for both CPUs when not booting with 'maxcpus=1' (see above):

# dmesg | grep -i ppc
[    0.520770] cpufreq-core: CPU 0: _PPC is 3 - frequency  limited
[    0.529676] cpufreq-core: CPU 1: _PPC is 3 - frequency  limited

Additionally, this is with the current BIOS:

dmidecode:
        Version: 7LETB0WW (2.10 )
        Release Date: 01/21/2008

So far, I did not have the battery plugged in and was working purely on AC power, but when I boot with the battery plugged in:

# dmesg | grep -i ppc
[    0.364325] cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
[    0.375427] cpufreq-core: CPU 1: _PPC is 0 - frequency not limited

This looks like a clear Lenovo BIOS bug and failure in validation to me!

Note that when booting on AC and inserting the battery later, the _PPC objects are (of course) not re-evaluated, thus we're still limited in this case.

Do Intel have any contact with Lenovo? I'll report the bug from my end, but blowing into the wind doesn't have much effect...

Created attachment 15056 [details]
dmesg with battery present at boot time and kernel options 'acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug=7'

HI, Daniel
    Thanks for what you have done. 
    The problem that the _PPC objects can't be re-valuated after plugging battery is caused by the broken bios. 
    Please report the bug to Lenovo.
    
    Because the bug is caused by broken bios, the bug will be rejected.

I have been unable to find any workaround for the stock Ubuntu 8.04 Hardy Heron kernel; the processor.ignore_ppc=1 option is not recognised. There will be a range of other distros in a similar situation.

I've escalated this to IBM/Lenovo as best I could.