Bug 5767

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.