Bug 5767 - C-state C1 does not get used when it is the only state available.
C-state C1 does not get used when it is the only state available.
Status: REJECTED DOCUMENTED
Product: ACPI
Classification: Unclassified
Component: Power-Processor
i386 Linux
: P2 normal
Assigned To: Venkatesh Pallipadi
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-20 23:47 UTC by Mats Johannesson
Modified: 2007-09-13 17:42 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.15-rc2
Tree: Mainline
Regression: ---


Attachments
acpidump (116.59 KB, text/plain)
2006-01-01 06:54 UTC, Mats Johannesson
Details

Description Mats Johannesson 2005-12-20 23:47:31 UTC
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.
Comment 1 Len Brown 2005-12-21 18:22:40 UTC
i thought we fixed this in a later-rc, can you try -rc6?
Comment 2 Mats Johannesson 2005-12-22 01:54:56 UTC
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;
 		}
 	}
Comment 3 Len Brown 2005-12-28 10:17:06 UTC
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!
Comment 4 Mats Johannesson 2006-01-01 06:52:33 UTC
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.
Comment 5 Mats Johannesson 2006-01-01 06:54:37 UTC
Created attachment 6910 [details]
acpidump
Comment 6 Len Brown 2007-08-19 00:11:39 UTC
> 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.
Comment 7 Mats Johannesson 2007-08-31 06:34:13 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.