Latest working kernel version: Earliest failing kernel version: 2.6.25.[9-14](fedora) 2.6.26.2(mainline) Distribution: Fedora 9 Hardware Environment: 2 Opteron 2356 on S2915 Tyan MB Software Environment: Problem Description: Cpuidle does not work on dual cpu quad-core Opteron system, sensors reports around 48C and 61C under 0 load for the first and second CPUs respectively. Both menu and ladder governors give similar results. Recompiling kernel with "CONFIG_CPU_IDLE is not set" gives around 35C and 41C under 0 load. Steps to reproduce:
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> </p><p>dmesg and 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> 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