Bug 10807

please attach acpidump output.

Created attachment 16302 [details]
acpidump with Arch-kernel 2.6.24.4

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.
            
       

Created attachment 16316 [details]
acpidump 2

Created attachment 16317 [details]
same as above, but disassembled with iasl

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.
        

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

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

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.

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.

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

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.

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)

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!

Forgot to say, it's the latest BIOS version and the only one I ever had installed.

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

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);

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.

i can't read the attachment in comment #16

Hi, Len
    It is a tar.gz file, which contains two patches. 

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.

+       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)

Created attachment 16519 [details]
the updated patch

The attached is the updated patch.

As the patch is available, this bug will be marked as resolved.

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.

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

now in Linus' tree

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.

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!

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.

Matthias,
please generate a patch and send it to ACPI mail list so that Yakui can follow up.

Created attachment 31762 [details]
delete DMI entry

deleting DMI entry as requested in comment #29

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