Most recent kernel where this bug did not occur: 2.6.15-rc1 Distribution: slamd64 Hardware Environment: x86_64 Software Environment: Problem Description: See below Steps to reproduce: Boot kernel As reported in http://marc.theaimsgroup.com/?l=linux-kernel&m=113513894606523&w=2 the one and only C-state C1 on my amd64 notebook got disabled by git commit: Fix ACPI processor power block initialization 2203d6ed448ff3b777ee6bb614a53e686b483e5b Linus chooses to prevent a "boot-time lockup" with that patch before enabling a C1 sleep state, but asked that I preserve the bug existence here. Hereby done.
i thought we fixed this in a later-rc, can you try -rc6?
I _am_ running 2.6.15-rc6 :) Patched with my own: diff -Nur linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c \ linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c --- linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c 2005-12-21 \ 13:29:12.000000000 +0100 +++ linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c 2005-12-21 \ 13:39:04.000000000 +0100 @@ -893,7 +893,7 @@ for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) { if (pr->power.states[i].valid) { pr->power.count = i; - if (pr->power.states[i].type >= ACPI_STATE_C2) + if (pr->power.states[i].type >= ACPI_STATE_C1) pr->flags.power = 1; } }
Good hunting, but i don't think this is the right code change to make. Does booting with "processor.nocst" make this issue go away? You mentioned that this is fixed in 2.6.15-rc5-mm3, can you test the patch in bug 4485 by itself (and no boot params)? Can you attach the complete output from acpidump? It is available in the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ thanks!
First, forget anything I've ever said about 2.6.15-rc5-mm3 (or other -mm-s). I unfortunately tagged along on a bugreport that was, and is, totally unrelated to the present issue. Sorry - won't happen again. My local fix was just a sledgehammer, intended for this machine only. Regarding your other queries: _Unpatched linux-2.6.15-rc7_ image = /boot/kernel-2.6.15-rc7-c1 label = 2.6.15-rc7-c1 root = /dev/hda2 append = "processor.nocst" active state: C1 max_cstate: C8 bus master activity: 00000000 states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000] _Patched linux-2.6.15-rc7_ http://bugzilla.kernel.org/attachment.cgi?id=6743&action=view (from bug 4485) image = /boot/kernel-2.6.15-rc7-c1 label = 2.6.15-rc7-c1 root = /dev/hda2 active state: C1 max_cstate: C8 bus master activity: 00000000 states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000] From my foggy understanding of the code, "pr->flags.power = 1" will never be set for anything lower than C2 - in accordance with linus' intent. Which is fine... I don't mind patching locally. I'll attach an acpidump as per request, but I'm rather confident in its 'correctness'. _Slightly OT_ I've tried hacking include/acpi/processor.h (upping ACPI_PROCESSOR_MAX_C2_LATENCY to overcome the manufacturer's sneaky 101 value), and then 2.6.15-rc7 proper uses both C1 and C2. The downside is that this leads to - significantly - _less_ powersave and _higher_ temperature than plain C1. On an amd64 processor something has to be done with the PCI bridge to enable C2. Can not find the correct info on the net. Phew, time to go.
Created attachment 6910 [details] acpidump
> upping ACPI_PROCESSOR_MAX_C2_LATENCY > to overcome the manufacturer's sneaky 101 value No, don't do this. Values over 100 are the official (not sneaky) way to tell the OS that the platform does not support C2. Reading my comments above, I think I misunderstood your report. Apparently I thought your box was the one with the boot hang. I believe that your report boils down to the lack of an incrementing counter in C1 in /proc/acpi/processor/*/power. I believe that is simply cosmetic and that you are still executing HLT or MWAIT as needed in C1. Assigning to Venkatesh, who is re-writing this code... Eventually we should have TSC-based cycle-accurate C-state residency. He may simply close this one as DOCUMENTED.
Ah, OK... not sneaky but an official statement that no C2 is available. I see. And I do agree that the lack of C1 increments are cosmetic (but also rather confusing for the end user). Please close this bug any time you wish.