Distribution: Debian Hardware Environment: P5 MMX 200 MHz CPU , 256 MB RAM, Supermicro motherboard 430 TX chipset, Adaptec PCI AHA-2940UW SCSI controller. Software Environment: Debian GNU Linux 3.0 (woody/stable) Problem Description: 2.4.18 and 2.4.20 both enabled C2 power saving on this system. Also the power button worked perfectly as a 'software' button and would switch the machine to runlevel 0. The 2.4.26 kernel with the new ACPI will not enable ACPI on the motherboard unless I use acpi=force (a regression in itself I feel) and then does not detect nor use the C2 power saving state available with this processor. Perhaps rather than just having a cut off BIOS date for enabling ACPI, a whitelist of manufacturers could be used too? I guess for some reason, C2 power saving is no longer being enabled for pentium mmx's. This makes the system run at about 15 Celsius hotter when switched on and idle. Badness. Steps to reproduce: Boot the kernel, notice that C2 power saving no longer shows up in dmesg output. I'll attach dmesg for you to see. If you need any help testing patches / want various config dumps just holler.
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.