Bug 10110

Summary: ACPI _PPC limiting processor speed...
Product: ACPI Reporter: Daniel J Blueman (daniel.blueman)
Component: BIOSAssignee: ykzhao (yakui.zhao)
Status: REJECTED WILL_NOT_FIX    
Severity: high CC: arekm
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.24 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Hex ACPI dump of T61 BIOS 2.09
Binary ACPI dump of T61 BIOS 2.09, for testing/debugging
Output of 'dmesg' with kernel booted with requested debug options only
Output from 'acpidump --addr 0x7d6e1b32 --length 0x2c4 -o cpu0ist'
Output from 'acpidump --addr 0x7d6e1e7b --length 0x85e -o cpu0cst'
acpi.debug_layer=0x1000000 dmesg from kernel booted with 'acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug=7 processor.ignore_ppc=1'
dmesg with battery present at boot time and kernel options 'acpi.debug_layer=0x1000000 acpi.debug_level=0x17 cpufreq.debug=7'

Description Daniel J Blueman 2008-02-26 00:12:10 UTC
Hardware Environment:
 - Lenovo T61 8897CTO
 - 2.2GHz 4MB L2$ Core2Duo mobile
 - 7LETA9WW/2.09 BIOS

Software Environment:
 - Ubuntu 8.04 Hardy prerel 64-bit
 - confirmed problem exists on:
  -> 2.6.24 mainline
  -> 2.6.25-rc3 mainline
  -> 2.6.23-rc
  -> Ubuntu 8.04 Hardy 2.6.24 kernels

Problem Description:
processor speed limited due to _PPC ACPI object - symptom of:

$ dmesg
cpufreq-core: CPU 0: _PPC is 3 - frequency  limited
cpufreq-core: CPU 1: _PPC is 0 - frequency not limited
[snip]
freq-table: table entry 0: 2201000 kHz, 0 index
freq-table: table entry 1: 2200000 kHz, 1 index
freq-table: table entry 2: 1600000 kHz, 2 index
freq-table: table entry 3: 1200000 kHz, 3 index
freq-table: table entry 4: 800000 kHz, 4 index

Steps to reproduce:
 1. (optional) ensure BIOS in T61 is late 2007
 2. boot 2.6.24 (or 2.6.23-rc, or 2.6.25-rc2)
Comment 1 Daniel J Blueman 2008-02-26 00:18:57 UTC
Created attachment 15000 [details]
Hex ACPI dump of T61 BIOS 2.09
Comment 2 Daniel J Blueman 2008-02-26 00:19:57 UTC
Created attachment 15001 [details]
Binary ACPI dump of T61 BIOS 2.09, for testing/debugging
Comment 3 ykzhao 2008-02-26 00:45:15 UTC
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.
Comment 4 ykzhao 2008-02-26 00:48:43 UTC
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.
Comment 5 ykzhao 2008-02-26 01:01:06 UTC
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.
Comment 6 Daniel J Blueman 2008-02-26 03:54:56 UTC
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?
Comment 7 Daniel J Blueman 2008-02-26 03:56:58 UTC
Created attachment 15008 [details]
Output of 'dmesg' with kernel booted with requested debug options only
Comment 8 Daniel J Blueman 2008-02-26 03:59:29 UTC
Created attachment 15009 [details]
Output from 'acpidump --addr 0x7d6e1b32 --length 0x2c4 -o cpu0ist'
Comment 9 Daniel J Blueman 2008-02-26 04:00:12 UTC
Created attachment 15010 [details]
Output from 'acpidump --addr 0x7d6e1e7b --length 0x85e -o cpu0cst'
Comment 10 Thomas Renninger 2008-02-26 05:06:41 UTC
Could it be that _PPC is evaluated at init time again with the latest thermal changes?

Also see:
git commit e4233dec749a3519069d9390561b5636a75c7579
Comment 11 Thomas Renninger 2008-02-26 05:27:11 UTC
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)
Comment 12 Daniel J Blueman 2008-02-26 05:31:12 UTC
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
Comment 13 Thomas Renninger 2008-02-26 07:07:25 UTC
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.
Comment 14 Daniel J Blueman 2008-02-26 07:32:45 UTC
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
Comment 15 ykzhao 2008-02-27 01:54:50 UTC
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.
Comment 16 Daniel J Blueman 2008-02-27 05:29:57 UTC
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
Comment 17 Daniel J Blueman 2008-02-27 05:41:06 UTC
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'
Comment 18 ykzhao 2008-02-27 19:01:21 UTC
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.
 
Comment 19 Daniel J Blueman 2008-02-28 02:32:25 UTC
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
Comment 20 Daniel J Blueman 2008-02-28 02:42:13 UTC
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...
Comment 21 Daniel J Blueman 2008-02-28 02:43:59 UTC
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'
Comment 22 ykzhao 2008-02-28 06:18:55 UTC
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.
Comment 23 Daniel J Blueman 2008-04-05 11:28:57 UTC
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.