Bug 3165
Summary: | No longer get C2 power saving detected | ||
---|---|---|---|
Product: | ACPI | Reporter: | Stuart Rowan (kernel-bugs) |
Component: | Power-Processor | Assignee: | Venkatesh Pallipadi (venki) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | acpi-bugzilla, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.14.3 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
dmesg output showing lack of C2
acpidmp output, run on Linux 2.4.30 dmesg from vanilla 2.4.30 with all acpi compiled in. dmesg from vanilla 2.4.30 with acpi_os_name set to Linux proc/acpi/processor/CPU1/power dmesg from vanilla 2.4.18 with all acpi compiled in proc/acpi/processor/0/status dmesg from 2.6.13.3 dmesg with acpi debug turned on a bit |
Description
Stuart Rowan
2004-08-05 08:05:37 UTC
Created attachment 3476 [details]
dmesg output showing lack of C2
please attach the dmesg resulting from no kernel parameters. What kernel was able to support C2? Can you attach the dmesg and /proc/acpi/processor/CPU0/power from that boot? what about newer kernels such as 2.4.27 and 2.6.9? 2.4.18-1-586tsc as found in Debian woody stable works fine. I am away at the moment so it will be difficult to get the dmesg for you. The big acpi update/merge circa 2.4.20/21/22 (I can't remember -- the huge patch anyway) was what changed the behaviour I think. Not that helpful i know. I will get you the requested information as soon as possible. Thanks for looking into this! Stu. please attach the output from acpidmp, available in /usr/sbin or in pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils It will show us what the BIOS says about C2 support. Also, you might try booting with "acpi_os_name=Linux" to see if that makes any difference. Okay so sorry for the wait but here is (hopefully) all the information you asked for. To follow, attached are: acpidmp output dmesg from vanilla 2.4.30 with all acpi compiled in. dmesg from vanilla 2.4.30 with acpi_os_name set to Linux proc/acpi/processor/CPU1/power for vanilla 2.4.30 (not CPU0 as you said -- presume the name changed at some point. FYI this is *not* an SMP box) dmesg from vanilla 2.4.18 with all acpi compiled in (notice the C2 detection) proc/acpi/processor/0/status displaying C2 state usage So if there's anything more you need or that I can help with, please let me know. Finally I have bumped the "Kernel Version" in the bug report. Many thanks, Stu. Created attachment 4934 [details]
acpidmp output, run on Linux 2.4.30
acpidmp output, acpidmp run on Linux 2.4.30
Created attachment 4935 [details]
dmesg from vanilla 2.4.30 with all acpi compiled in.
Created attachment 4936 [details]
dmesg from vanilla 2.4.30 with acpi_os_name set to Linux
Created attachment 4937 [details]
proc/acpi/processor/CPU1/power
Created attachment 4938 [details]
dmesg from vanilla 2.4.18 with all acpi compiled in
Created attachment 4939 [details]
proc/acpi/processor/0/status
> Linux version 2.4.18 > ACPI: Core Subsystem version [20011018] > Processor[0]: C0 C1 C2 > Linux version 2.4.30 > ACPI: Subsystem revision 20040326 > ACPI: Processor [CPU1] (supports C1) Yep, C2 went away. DSDT does not contain a _CST method, so this should depend only on the FADT support. Looking at the FADT: P_LVL2_LAT: 100 P_LVL3_LAT: 1000 Which is the BIOS telling us that this system supports not only C2, but also C3 -- at the maximum allowable latency. Is this issue reproducible with a recent kernel, like 2.6.13? Fully reproducible with 2.6.13.3 new dmesg attached. Thanks. Created attachment 6292 [details]
dmesg from 2.6.13.3
Is this reproducible with 2.6.14? 2.6.14.2 still just reporting C1 I'll attach various things if people want? Created attachment 6741 [details]
dmesg with acpi debug turned on a bit
So here's a better dmesg. I googled some command line values for debug because
the documentation (kernel-parameters.txt) is worse than crap (!) So if you want
better / different debug output, you'd better tell me what values you want.
Interesting things this shows:
Linux works out there is no _CST
It gives up looking at the FADT and returns (I think) -ENODEV
So if we can get it to look at the FADT that would be super, the exit out of
acpi_processor_get_power_info_fadt() seems to be caused by linux not seeing a
pblk / PBLK for the processor whatever that is!
Does this help narrow down the problem?
the dmesg.txt is gzipped. This seems to be making firefox here at least cry but if i save to file and then decompress and view myself all is good. Thanks for all your hard work people :-) [42949374.110000] acpi_processor-0509 [08] processor_get_power_in: ----Entry [42949374.110000] acpi_processor-0515 [08] processor_get_power_in: ----Exit- FFFFFFFFFFFFFFED is here: ACPI_FUNCTION_TRACE("acpi_processor_get_power_info_fadt"); if (!pr) return_VALUE(-EINVAL); if (!pr->pblk) return_VALUE(-ENODEV); Looking at the DSDT: Scope (\_PR) { Processor (CPU1, 0x01, 0x00000000, 0x00) {} } So it does appear that the PBLK and PBLK-length are 0 -- yet 2.4.18 was able to enable C2 without this... Please verify that this regression still exists in 2.6.22.stable I expect it will be. It isn't clear how 2.4 was getting the C2 address, or why it wasn't also exposing C3, for that matter. Closing the bug. Please reopen if you still see this problem. |