Bug 11345

Hi, Vit
   Will you please attach the output of acpidump?
   Do you mean that the sensor temperature in case of enabling CONFIG_CPU_IDLE is above than that in case of unseting CONFIG_CPU_IDLE? Right? Will you please add the boot option of "maxcpus=1" in the above two cases and see whether the difference still exists?

Thanks.

Hi,

   That is right. With CONFIG_CPU_IDLE enabled the sensors 
temparature
is higher.

   With maxcpus=1 the difference stil exists.

    acpidump is attached.

   Thanks.

>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11345
>
> ------- Comment #1 from yakui.zhao@intel.com  2008-08-17 
> 07:34
> -------
> Hi, Vit
>    Will you please attach the output of acpidump?
>    Do you mean that the sensor temperature in case of 
> enabling
> CONFIG_CPU_IDLE
> is above than that in case of unseting CONFIG_CPU_IDLE? 
> Right? Will
> you please
> add the boot option of "maxcpus=1" in the above two cases 
> and see
> whether the
> difference still exists?
>
> Thanks.
>
> -- 
> Configure bugmail: 
> http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

Also, can you attach the output of 'dmesg' and the output of command
# grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/*
with CPU_IDLE enabled.

dmesg and  grep . 
/sys/devices/system/cpu/cpu*/cpuidle/state*/*
attached

> http://bugzilla.kernel.org/show_bug.cgi?id=11345
>
> ------- Comment #3 from venkatesh.pallipadi@intel.com  
> 2008-08-18
> 16:44 -------
> Also, can you attach the output of 'dmesg' and the output 
> of command
> # grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/*
> with CPU_IDLE enabled.
>
> -- 
> Configure bugmail: 
> http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

??? ????? ?????.??<p>&nbsp;</p><p>dmesg and&nbsp; grep .
/sys/devices/system/cpu/cpu*/cpuidle/state*/* attached</p><blockquote
style="border-left: 2px dotted rgb(170, 170, 170); margin: 10px 10px 10px 0px;
padding-left: 10px;"><div><a
href="http://bugzilla.kernel.org/show_bug.cgi?id=11345"
mce_href="http://bugzilla.kernel.org/show_bug.cgi?id=11345"
target="_blank">http://bugzilla.kernel.org/show_bug.cgi?id=11345</a><br>
<br>
<br>
<br>
<br>
<br>
------- Comment #3 from <a href="mailto:venkatesh.pallipadi@intel.com"
mce_href="mailto:venkatesh.pallipadi@intel.com" title="New Message to
venkatesh.pallipadi@intel.com">venkatesh.pallipadi@intel.com</a>&nbsp;
2008-08-18 16:44 -------<br>
Also, can you attach the output of 'dmesg' and the output of command<br>
# grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/*<br>
with CPU_IDLE enabled.<br>
<br>
<br>
-- <br>
Configure bugmail: <a href="http://bugzilla.kernel.org/userprefs.cgi?tab=email"
mce_href="http://bugzilla.kernel.org/userprefs.cgi?tab=email"
target="_blank">http://bugzilla.kernel.org/userprefs.cgi?tab=email</a><br>
------- You are receiving this mail because: -------<br>
You reported the bug, or are watching the
reporter.</div></blockquote><br><br><br><br>
??? ????? <a href="http://www.pochta.ru/">?????.??</a>

Created attachment 17316 [details]
acpidump

Created attachment 17317 [details]
dmesg output

Created attachment 17318 [details]
grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/*

dmesg says that ACPI exports 3 C-states:

ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])


But CPUIDLE sees and uses just C1:
Further, CPUIDLE has a NULL description for C1, which doesn't look right:

/sys/devices/system/cpu/cpu0/cpuidle/state1/desc:<null>
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/time:202562479
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage:30678

Please _paste_ (or attach if you must), the output from
grep . /proc/acpi/processor/*/power

when CPUIDLE is disabled.

Created attachment 17377 [details]
grep . /proc/acpi/processor/*/power

Not sure if this is the exact same problem, but it looks like cpuidle doesn't work at all for me. Two different machines, one an Opteron 185 dual-core SMP kernel (Asus A8V) and one a Turion ZM-80 dual-core SMP (laptop, HP dv5z again). Both are running 2.6.26.3.

In /sys/devices/system/cpu/cpu*/* there is no cpuidle directory at all. As far as I can tell the system is never entering the C1 state.

I also have an Asus M6Ne laptop running this same kernel version, and cpuidle appears to be working correctly there (processor is a Pentium M 755).

Looks like the BIOS is advertising C1, C2 and C3 states only for CPU 0 and there are no C-states exported for other CPUs at all. !CPU_IDLE case seems to be using C1 on all CPUs.
This is possibly confusing the cpuidle governor. Will look at the code and post a test/workaround patch soon.

Regardless of this CPUIDLE bug, if the CPU really supports C2, C3 and only CPU 0 advertises these states, then there is something wrong in the BIOS. We  will not be using C2, C3 both with or without CPUIDLE. Mark should be able to shed more light into this part.

Created attachment 17451 [details]
Test patch

Attached patch should resolve the problem. Can you please try it and verify.

Thanks,
Venki

The BIOS is clearly buggy.  C1 should be supported on all processors and C3 is not available on SMP Opteron systems with quad-core.

With the test patch kernel just hangs after 

cpuidle: using governor menu

Created attachment 17536 [details]
Test patch


Sorry. I overlooked things in the earlier patch. This patch should fare better....

This patch works. The temperature is lower now (although it is a little bit higher than with !CPUIDLE)

Created attachment 17977 [details]
Refreshed patch

I am not sure why the temperature is not sama as !CPUIDLE case. Does the number of wakeups or C-state residency in powertop is any different with and without !CPUIDLE

Venki, what's the status of the patch?

patch in comment #17 applied to acpi-test cpuidle branch

For the record, the bug here isn't that C2 and C3 were
not seen, as originally reported.

While C2 and C3 values are reported in the FADT,
FADT.P_LVL2_UP is 0, which means that C2 is _not_
supported on SMP mode on this box.

So ACPI is properly not using C2 and C3 on CPU0.
Indeed, we should fix /proc/acpi/processor/*/power
so that it doesn't even mention them in SMP mode.

We could probably use them in UP mode, but this
box would be pretty un-interesting in UP mode.

But the more important bug, which is fixed by venki's patch
above, is that when the processors did not have a _CST,
we were polling instead of using C1 on all processors.

shipped in linux-2.6.28-rc1
closed

commit 89cedfefca1d446ee2598fd3bcbb23ee3802e26a
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Date:   Thu Oct 16 19:00:08 2008 -0400

    cpuidle: upon BIOS bug, default to default_idle rather than polling