Bug 10807 - ACPI C-State missing since 2.6.19.3
ACPI C-State missing since 2.6.19.3
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: BIOS
All Linux
: P1 normal
Assigned To: ykzhao
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-27 10:31 UTC by Matthias
Modified: 2010-10-02 01:59 UTC (History)
4 users (show)

See Also:
Kernel Version: >= 2.6.19.3
Tree: Mainline
Regression: Yes


Attachments
acpidump with Arch-kernel 2.6.24.4 (142.93 KB, application/octet-stream)
2008-05-28 03:03 UTC, Matthias
Details
acpidump 2 (872 bytes, application/gzip)
2008-05-29 07:29 UTC, Matthias
Details
same as above, but disassembled with iasl (2.08 KB, application/gzip)
2008-05-29 07:35 UTC, Matthias
Details
try the debug patch (734 bytes, patch)
2008-05-29 19:15 UTC, ykzhao
Details | Diff
use the attached tool to get the Mwait outputs (970 bytes, patch)
2008-06-01 19:33 UTC, ykzhao
Details | Diff
dmidecode output (6.59 KB, application/octet-stream)
2008-06-05 09:34 UTC, Matthias
Details
test the debug patch (1.74 KB, patch)
2008-06-05 22:21 UTC, ykzhao
Details | Diff
the updated patch (3.07 KB, patch)
2008-06-16 23:46 UTC, ykzhao
Details | Diff
patch vs 2.6.26-rc6 (5.73 KB, patch)
2008-06-19 23:40 UTC, Len Brown
Details | Diff
delete DMI entry (1.17 KB, patch)
2010-09-28 21:24 UTC, Len Brown
Details | Diff

Description Matthias 2008-05-27 10:31:24 UTC
Latest working kernel version: 2.6.18.8
Kernel 2.6.19 to 2.6.19.2 won't compile, so not tested
Earliest failing kernel version: 2.6.19.3
Distribution: Arch Linux
Hardware Environment:
 * Intel Pentium Dual-Core / Core 2 Duo CPU
 * Intel GM965 / PM965 Chipset
Software Environment: Vanilla-kernel

Problem Description:
ACPI C3-State (Pentium) or C4-State (Core 2) isn't detected anymore and laptop consumes more power. I've also tested some other Live-CDs: if kernel <= 2.6.18.8 C3 works, if kernel is newer C3 doesn't work. Problem still exists in version 2.6.25.4.

Bootmessages kernel version 2.16.18.8:
Allocate Port Service[0000:00:1c.5:pcie02]
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Power Button (CM) [PWRB]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Ist] [20060707]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Cst] [20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Ist] [20060707]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Cst] [20060707]
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12ac

2.6.19.3:
Allocate Port Service[0000:00:1c.5:pcie02]
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Power Button (CM) [PWRB]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Ist] [20060707]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Cst] [20060707]
Monitor-Mwait will be used to enter C-1 state
Monitor-Mwait will be used to enter C-2 state
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Ist] [20060707]
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Cst] [20060707]
ACPI: CPU1 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12ac

/proc/acpi/processor/CPU0/power 2.6.18.8:
active state:            C3
max_cstate:              C8
bus master activity:     00000000
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[000] usage[00000010] duration[00000000000000000000]
    C2:                  type[C2] promotion[C3] demotion[C1] latency[001] usage[00000060] duration[00000000000000352022]
   *C3:                  type[C3] promotion[--] demotion[C2] latency[017] usage[00034890] duration[00000000000477579415]

2.6.19.3:
active state:            C2
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 8000 usec
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001] usage[00000370] duration[00000000000000000000]
   *C2:                  type[C2] promotion[--] demotion[C1] latency[017] usage[00023870] duration[00000000000166137636]

"acpitool -c" 2.6.18.8:
  CPU type               : Intel(R) Pentium(R) Dual  CPU  T2330  @ 1.60GHz 
  CPU speed              : 1596.004 MHz 
  Cache size             : 1024 KB
  Bogomips               : 3196.88 
  Bogomips               : 3192.11 

  # of CPU's found       : 2

  Processor ID           : 0
  Bus mastering control  : yes
  Power management       : yes
  Throttling control     : yes
  Limit interface        : yes
  Active C-state         : C3
  C-states (incl. C0)    : 3
  Usage of state C1      : 60 (0.2 %)
  Usage of state C2      : 39778 (99.8 %)
  T-state count          : 8
  Active T-state         : T0


  Processor ID           : 1
  Bus mastering control  : yes
  Power management       : yes
  Throttling control     : yes
  Limit interface        : yes
  Active C-state         : C3
  C-states (incl. C0)    : 3
  Usage of state C1      : 128 (0.2 %)
  Usage of state C2      : 75167 (99.8 %)
  T-state count          : 8
  Active T-state         : T0

2.6.19.3:
  CPU type               : Intel(R) Pentium(R) Dual  CPU  T2330  @ 1.60GHz 
  CPU speed              : 1596.005 MHz 
  Cache size             : 1024 KB
  Bogomips               : 3196.92 
  Bogomips               : 3192.04 

  # of CPU's found       : 2

  Processor ID           : 0
  Bus mastering control  : yes
  Power management       : yes
  Throttling control     : yes
  Limit interface        : yes
  Active C-state         : C2
  C-states (incl. C0)    : 3
  Usage of state C1      : 440 (1.3 %)
  Usage of state C2      : 33768 (98.7 %)
  T-state count          : 8
  Active T-state         : T0


  Processor ID           : 1
  Bus mastering control  : yes
  Power management       : yes
  Throttling control     : yes
  Limit interface        : yes
  Active C-state         : C1
  C-states (incl. C0)    : 3
  Usage of state C1      : 273 (0.7 %)
  Usage of state C2      : 2642 (7.2 %)
  T-state count          : 8
  Active T-state         : T0
Comment 1 Shaohua 2008-05-27 18:57:28 UTC
please attach acpidump output.
Comment 2 Matthias 2008-05-28 03:03:49 UTC
Created attachment 16302 [details]
acpidump with Arch-kernel 2.6.24.4
Comment 3 ykzhao 2008-05-28 22:31:29 UTC
Will you please attach the following outputs?
   acpidump --addr 0x3f6d8b70 --length 0x238 -o cpu0ist
   acpidump --addr 0x3f6d8501 --length 0x5ea -o cpu0cst
   acpidump --addr 0x3f6d8da8 --length 0xc8  -o cpu1ist
   acpidump --addr 0x3f6d8aeb --length 0x85  -o cpu1cst
   Thanks.
            
       
Comment 4 Matthias 2008-05-29 07:29:31 UTC
Created attachment 16316 [details]
acpidump 2
Comment 5 Matthias 2008-05-29 07:35:41 UTC
Created attachment 16317 [details]
same as above, but disassembled with iasl
Comment 6 ykzhao 2008-05-29 18:27:56 UTC
Hi, Matthias
    After the following patch is applied, OSPM is capable of performing native C state instructions for the C2/C3 handler(Fixed Hardware access mode is supported). And OSPM will pass the differnet argument to the BIOS.
    >commit 991528d7348667924176f3e29addea0675298944
    >Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    > Date:   Mon Sep 25 16:28:13 2006 -0700
       >ACPI: Processor native C-states using MWAIT
    In such case only C1/C2 is returned by the _CST object. So the laptop can't enter C3 any more. 
    
    Before the above commit is merged, the C1/C2/C3 is returned by the _CST object and the laptop can enter C3.
        
Comment 7 ykzhao 2008-05-29 19:15:41 UTC
Created attachment 16331 [details]
try the debug patch

Will you please try the debug patch and see whether the problem still exists?
In this debug patch the C2C3_FFH access mode will be disabled if the mwait/monitor feature is unsupported.
Thanks
Comment 8 Matthias 2008-05-30 08:35:15 UTC
Thanks for the patch. I tried it with kernel 2.6.25.4, but unfortunately still no C3:
cat /sys/devices/system/cpu/cpu?/cpuidle/state?/desc
CPUIDLE CORE POLL IDLE
ACPI FFH INTEL MWAIT 0x0
ACPI FFH INTEL MWAIT 0x20
CPUIDLE CORE POLL IDLE
ACPI FFH INTEL MWAIT 0x0
ACPI FFH INTEL MWAIT 0x20
Comment 9 ykzhao 2008-06-01 19:33:47 UTC
Created attachment 16358 [details]
use the attached tool to get the Mwait outputs

Will you please use the attached tool to get the Mwait outputs?
Thanks.
Comment 10 ykzhao 2008-06-01 19:41:31 UTC
Thanks for the test.
   From the log in comment #8 it seems that Monitor/Mwait is supported on your laptop and C2C3_FFH access mode will be enabled. In such case only the C1/C2 is returned by the _CST object.
   From the log the issue is that C3 state is missing on the latest kernel. But how can you confirm whether the laptop will consume more power using 2.6.22 than the early kernel?
   Anyway , please use the attached tool to get the MWait output.
Comment 11 Matthias 2008-06-02 01:35:41 UTC
I see, it's the manufacturer's fault that it doesn't work, isn't it?
I can see the higher power consumption most clearly by the faster coretemperature increase of the CPU when the fan is off and CPU is idle. It can almost run without fan if idle and C3 works.
I'm not sure if I can trust the output of acpitool and powertop that the second CPU is at most 50% in C2. Curiously I can see it 100% in C2 after suspend-to-ram and I guess that it is actually in C3.
I can't test the tool now but I will do it later.

Thanks a lot
Comment 12 Matthias 2008-06-02 08:48:37 UTC
cpuid output:
Mwait is supported

 MMait leaf:
eax is 40
ebx is 40
ecx is 3
edx is 1110

Is there anything I could do to test what changes after STR? The usual things (powertop, /proc/acpi/processor, /sys/devices/system/cpu, acpitool) don't display anything special except higher C2 usage.
Comment 13 Len Brown 2008-06-04 22:38:37 UTC
Clearly a BIOS bug.
Please attach the output from dmidecode so we can recognize this
system and automatically invoke a workaround.
(which will be to disable mwait on this box)
Comment 14 Matthias 2008-06-05 09:34:46 UTC
Created attachment 16404 [details]
dmidecode output

It's this laptop: http://uk.zepto.com/Shop/Notebook.aspx?notebookid=673
based on a Compal barebone

Thanks for your effort!
Comment 15 Matthias 2008-06-05 09:40:05 UTC
Forgot to say, it's the latest BIOS version and the only one I ever had installed.
Comment 16 ykzhao 2008-06-05 22:21:15 UTC
Created attachment 16410 [details]
test the debug patch

Will you please try the debug patch and see whether the problem still exists?
In the debug patch mwait won't be used for CPU C-states. 
Thanks
Comment 17 Matthias 2008-06-06 07:07:17 UTC
Thanks, the patch works. In contrast to kernel 2.6.18, acpitool detects all C-States.
But it still says C0 would be active. Shall I analyze this, too? C3 is surely working. This bug must have its cause in the changes between 2.6.19 an 2.6.24.
There must also have been a problem with mwait and wakeups measured by powertop. With mwait there were too much wakeups powertop couldn't find an origin for (e.g. 20.000 with 2.6.25.4). I can't believe this being true.

+		"disable mwait for CPU C-stetes", id->ident);

+		"disable mwait for CPU C-states\n", id->ident);
Comment 18 ykzhao 2008-06-12 22:06:22 UTC
Thanks for the test. It seems that the problem can be fixed by the patch in comment #16.

From the log in comment #12 we know that MWAIT is supported on your laptop. But there are some problems when the mwait is used for CPU C-states. For example: C3-state is missing and powertop can't find the original reason for the too many wakeup events. So it will be better to not use MWAIT for CPU-cstate on your laptop. The follwing info only tell us that mwait is disabled for CPU C-states.  
   > +               "disable mwait for CPU C-stetes", id->ident);

For the problem that proc I/F says C0 would be active, you needn't analyze the reason. It is related with kernel configuration. If CONFIG_CPU_IDLE is set in kernel configuration, the Proc I/F will always say that C0 is active. In such case sys I/F had better be used. 

As the problem can be fixed by the patch in comment #16, the bug can be marked as resovled.

Thanks.

Comment 19 Len Brown 2008-06-12 22:21:58 UTC
i can't read the attachment in comment #16
Comment 20 ykzhao 2008-06-13 00:21:19 UTC
Hi, Len
    It is a tar.gz file, which contains two patches. 
Comment 21 Matthias 2008-06-13 00:43:41 UTC
I sent a mail to Zepto about the bug, but I didn't get an answer yet.
Windows Vista is also using MWAIT, isn't it? I will test that, too.
Comment 22 Len Brown 2008-06-13 18:38:11 UTC
+       processor.idle= [HW,ACPI]
+                       { 1 } disable MWait for CPU C-states even when MWAIT
+                       is supported

process.c already has an "idle=mwait" param.
please create "idle=nomwait" rather than creating an entirely new processor module parameter.

(while you're there, we need another patch to create "idle=halt" that will force the system to use just the HALT instruction (ie. no mwait an C1 only)

Comment 23 ykzhao 2008-06-16 23:46:37 UTC
Created attachment 16519 [details]
the updated patch

The attached is the updated patch.
Comment 24 ykzhao 2008-06-17 18:22:50 UTC
As the patch is available, this bug will be marked as resolved.
Comment 25 Len Brown 2008-06-19 23:24:40 UTC
1. disable_mwait.patch applied
2. idle_halt.patch applied

3. process_idle.patch appears to be the wrong version
as it still has a module parameter processor.idle=1

4. dmi_idle.patch depends on #3, which is not applied.
Comment 26 Len Brown 2008-06-19 23:40:34 UTC
Created attachment 16558 [details]
patch vs 2.6.26-rc6

the correct patch series was on the e-mail list.
here are the 4 patches combined into one for
easy testing vs 2.6.26-rc6
Comment 27 Adrian Bunk 2008-07-16 15:37:56 UTC
now in Linus' tree
Comment 28 Matthias 2008-12-13 10:33:43 UTC
Sorry for disturbing again.
I heard from another owner of this buggy laptop that his newer Core 2 Duo does not have C6 since disabling mwait. So this problem is dependent on the cpu, too.
However there is no facility to re-enable mwait without deleting the board from __cpuinitdata processor_idle_dmi_table[]. idle=mwait results in having no c-states at all.
I would be satisfied with the new idle=nomwait parameter, so you may delete the board as easiest solution.

Thanks

BTW: Windows Vista must be using C3-state, so apparently it doesn't use mwait.
Comment 29 Matthias 2010-05-05 18:21:15 UTC
I'm reopening this bug because some people have drawbacks when not using mwait (as said in previous comment) and now there is no possibility to re-enable mwait without recompiling the whole kernel.

Please remove the IFL91 entry from the table in /drivers/acpi/processor_pdc.c. I'm just fine with using idle=nomwait to save 5 watts (even not using c-states at all saves 2 watts).

Thanks a lot!
Comment 30 ykzhao 2010-06-12 06:55:42 UTC
Hi, Matthias
     Sorry for the late response.
     Can you write the corresponding patch and send it to the linux-acpi@vger.kernel.org list? Then I can add "acked-by" to make it hit the upstream kernel.

thanks.
Comment 31 Zhang Rui 2010-06-30 06:17:36 UTC
Matthias,
please generate a patch and send it to ACPI mail list so that Yakui can follow up.
Comment 32 Len Brown 2010-09-28 21:24:21 UTC
Created attachment 31762 [details]
delete DMI entry

deleting DMI entry as requested in comment #29
Comment 33 Len Brown 2010-10-02 01:59:21 UTC
commit 64a32307b710c100beb101e9c78f8022f0e8ba61
Author: Len Brown <len.brown@intel.com>
Date:   Tue Sep 28 17:20:20 2010 -0400

    ACPI: delete ZEPTO idle=nomwait DMI quirk


shipped in 2.6.36-rc6-git2
closed

Note You need to log in before you can comment on or make changes to this bug.