I have two different systems on which the aforementioned bug can be reproduced. The first is a desktop PC with an Asus P5PE-VM board and an Intel Pentium 4 631 3.0GHz cpu, and the second is a Lenovo S110 netbook with an Intel Atom N2800 1.83Ghz cpu. The bios setup option on the desktop has an 'Enhanced C1 control' option that is set to auto/enabled, while the netbook has no user-configurable options related to cpu idle states. Both systems are running Linux-3.12. I tried booting with and without the intel_idle.max_cstate=0 and processor.nocst=1 kernel parameters for testing, and here are the following results: Desktop, without the two parameters: $ dmesg | grep idle cpuidle: using governor ladder cpuidle: using governor menu $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:none /sys/devices/system/cpu/cpuidle/current_governor_ro:menu Desktop, with the two parameters: $ dmesg | grep idle cpuidle: using governor ladder cpuidle: using governor menu intel_idle: disabled $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:none /sys/devices/system/cpu/cpuidle/current_governor_ro:menu Netbook, without the two parameters: $ dmesg | grep idle intel_idle: does not run on family 6 model 54 cpuidle: using governor ladder cpuidle: using governor menu $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:none /sys/devices/system/cpu/cpuidle/current_governor_ro:menu Netbook, with the two parameters: cpuidle: using governor ladder cpuidle: using governor menu intel_idle: disabled $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:none /sys/devices/system/cpu/cpuidle/current_governor_ro:menu As can be seen, the acpi_idle driver is not registering with cpuidle no matter the parameters used, and Powertop-2.5 shows up empty in the Idle State tab. The kernel has the necessary config options enabled: CONFIG_ACPI_PROCESSOR=y CONFIG_CPU_IDLE=y I tried booting up a legacy live cd with a Linux-2.6.38 kernel on the desktop, and I have observed a significant difference: $ dmesg | grep idle using mwait in idle threads. ACPI: acpi_idle registered with cpuidle cpuidle: using governor ladder cpuidle: using governor menu $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:acpi_idle /sys/devices/system/cpu/cpuidle/current_governor_ro:menu I understand that there has been a change from using acpi_idle to intel_idle, and by passing intel_idle.max_cstate=0 as per documentation, the acpi_idle driver may be used again. But my questions are: 1. Why doesn't the intel_idle driver support my Intel Pentium 4 631 and Intel Atom N2800 cpus?, and finally 2. Given that intel_idle doesn't seem to support the two aforementioned cpus, why is the acpi_idle driver not loading instead when intel_idle is disabled? Could it be perhaps that the change has somehow broken acpi_idle?
For #1 see and test https://lkml.org/lkml/2014/1/25/140 Feedback would I am sure be useful.
Yes I have: https://bugzilla.kernel.org/show_bug.cgi?id=60201 Though, I never got around to submitting my patch. Patching intel_idle, I am getting the following results on the netbook as follows: $ dmesg | grep idle intel_idle: MWAIT substates: 0x3020220 intel_idle: v0.4 model 0x36 intel_idle: lapic_timer_reliable_states 0xffffffff cpuidle: using governor ladder cpuidle: using governor menu $ grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:intel_idle /sys/devices/system/cpu/cpuidle/current_governor_ro:menu
Created attachment 123981 [details] dmesg output on the desktop, with intel_idle.max_cstate=0 and processor.nocst=1
Created attachment 123991 [details] dmesg output on the netbook, with intel_idle.max_cstate=0 and processor.nocst=1
Reading https://lwn.net/Articles/390427/ I can understand the move from acpi_idle to intel_idle. However, seeing that a week has passed and still no word from the maintainer, I was left wondering: While intel_idle currently only supports Nehalem-, most Atom-, Lincroft-, Ivy Bridge-, Sandy Bridge-, and recently Haswell- and Avoton-based procies from its code, what about all the other Intel procies released in the past that could benefit from the potential power savings of directly controlling their idle states in Linux? Almost four years have passed since that article was published, and yet nothing since then has changed to show support for other Intel processors. Moving forward, it looks like only new processors that Intel will release will get support in intel_idle.
You are much better off asking on the mailing list ot be honest. It definitely should be falling back. For the N2800 I'd submit your patch. It seems to work on my N2800
Thanks Alan. Let me know if you need anything else on submitting the patch. And yes it should be falling back to acpi_idle but isn't. Do bug reports have a high chance of getting audience in the mailing list than reporting it here first? I'll checkout the mailing list later.
Well ideally you'd submit it but if nt I'll add it to the queue. I do need a Signed-off-by: from you for it however (See Documentation/SubmittingBugs) In general yes - the mailing lists generate more audience and also hit a wider number of people (and thus ideas). Bugzilla is good at ensuring specific bugs are not lost, mailing lists at getting them fixed.
You can set it as Signed-off-by: Ian Pangilinan <snailbox88-dev@yahoo.com>
cpuidle and its drivers will not register on machines that support only 1 idle state -- as there is no state decision to be made on such machines. Are you sure your P4 supports more than 1 C-state? Generally, the mobile P4's did, and other P4's did not. Why are both machines booted with "processor.nocst=1"? I will not support intel_idle on P4, and other older processors, for a number of reasons - but the summary is all pain, no gain. The Atom is another story. The group that uses Linux on those processors never submitted an upstream patch to support cpuid 0x36. I don't know why. I think it merits a look.
(In reply to Len Brown from comment #10) > Are you sure your P4 supports more than 1 C-state? > Generally, the mobile P4's did, and other P4's did not. As far as my understanding goes, and as per Section 6.2 of the datasheet on Intel Pentium 4 Processor 6x1 Sequence [1], to wit: 6.2.1 Normal State 6.2.2 HALT and Enhanced HALT Powerdown States 6.2.3 Stop Grant State which I understand corresponds to C0, C1 / C1E, and C2 low power states respectively, excluding C0 of course, counting at least two C-states for this particular Pentium 4. [1] http://www.intel.com/Assets/PDF/datasheet/310308.pdf > Why are both machines booted with "processor.nocst=1"? Because even with only intel_idle.max_cstate=0, cpuidle still does not fallback to acpi_idle the way it's supposed to, at least according to the current Linux 3.13 documentation. So I thought it might help with troubleshooting this bug by falling back to legacy _FADT method of determining C-states. > I will not support intel_idle on P4, and other older processors, > for a number of reasons - but the summary is all pain, no gain. I understand that there have been many iterations of the Intel Pentium 4 model during its lifetime. Not all of them have low power states, truer so on the desktop P4's. But AFAICT, this Intel Pentium 4 631, codenamed Cedar Mill, appears to support at least two C-states. I do have another desktop with an Intel Core 2 Duo E8400, much newer than my Intel Pentium 4 631, and yet intel_idle does not run on this family 6 model 23 processor, despite Section 6.2 of the datasheet on Intel Core 2 Duo E8000 and E7000 Series [2] indicating that this processor supports more than one idle states, to wit: 6.2.1 Normal State 6.2.2 HALT and Extended HALT Powerdown States 6.2.3 Stop Grant and Extended Stop Grant States 6.2.5 Sleep State 6.2.6 Deep Sleep State 6.2.7 Deeper Sleep State which corresponds to C0, C1 / C1E, C2 / C2E, C3, and C4 low power states, respectively. [2] http://download.intel.com/design/processor/datashts/318732.pdf > The Atom is another story. > The group that uses Linux on those processors never submitted > an upstream patch to support cpuid 0x36. I don't know why. > I think it merits a look. Yes, thank you. And to provide you with further details surrounding the why, it is not only in intel_idle that this particular Atom (036h) is missing support. There is also no support for this Atom (036h) in the intel_powerclamp kernel module, even though another, previous generation Atom (01Ch) is supported.
(In reply to Len Brown from comment #10) > cpuidle and its drivers will not register on machines > that support only 1 idle state -- as there is no state > decision to be made on such machines. Then acpi_idle or cpuidle must be broken, because cpuidle does not register any drivers on the netbook with an Intel Atom N2800, codenamed Cedar Trail, that has more than one idle state.
Created attachment 126221 [details] dmesg on the core2duo desktop, normal boot
I understand that supporting older processors might not yield worthwhile gains compared to the amount of work that has to be done to add code in intel_idle for such processors, even if said processors support more than one C-state. Even though it would be nice to see direct support from intel_idle for at least Core 2 generation of processors, I think this will not happen anytime soon. Unless ACPI C-states have been deprecated in Linux in favor of vendor-specific intel_idle or assuming there isn't some obscure BIOS bug, I think there is a problem why the acpi_idle driver of cpuidle is not loading and handling C-states for processors not covered by the intel_idle driver, when said processors have been shown to support more than one C-state, i.e., the Intel Core 2 Duo E8400 and Intel Atom N2800 in this case.
I've tested multiple cases including N2800 and the acpi_idle driver registration always works for me if intel_idle doesn't grab the CPU. With the intel_idle changes added then intel_idle claims it and all seems to be working correctly. I can't reproduce any case where having intel_idle support enabled in a system doesn't let older processors fall through to acpi idle. intel_idle for N2800 is definitely better - I get much better battery life time.
(In reply to Alan from comment #15) > I've tested multiple cases including N2800 and the acpi_idle driver > registration always works for me if intel_idle doesn't grab the CPU. With > the intel_idle changes added then intel_idle claims it and all seems to be > working correctly. > I have expected the same behavior, but as you can see from my test results, this isn't what's happening, at least in two different systems of mine, no matter if using the distribution kernel or not, but both systems running a Ubuntu-based distribution. > I can't reproduce any case where having intel_idle support enabled in a > system doesn't let older processors fall through to acpi idle. > What kernel and distribution might you be running so that I may test them against mine as well?
Fedora and 3.13 upstream kernels.
I tried running Fedora 20 64-bit on bare metal and upstream 3.13 on my Core 2 Duo E8400 desktop, and still acpi_idle does not register with cpuidle, thus no C-states information can be read. The same can also be said on my laptop with Intel Atom N2800.
marking REOPENED, assigning to ACPI, as this is about acpi_idle. For the machines where acpi_idle fails to register... Please verify that they are running the latest production BIOS. Please verity that BIOS SETUP is set to defaults, and that C-states are not disabled in BIOS SETUP. Please attach the output from acpidump, and the latest dmesg.
(In reply to Len Brown from comment #19) > marking REOPENED, assigning to ACPI, as this is about acpi_idle. > > For the machines where acpi_idle fails to register... > > Please verify that they are running the latest production BIOS. > Please verity that BIOS SETUP is set to defaults, and that > C-states are not disabled in BIOS SETUP. > Please attach the output from acpidump, and the latest dmesg. I'm attaching the latest dmesg and acpidump outputs for the Lenovo S110 laptop with Intel Atom N2800. The Driver Downloads page for this model from the Lenovo support site doesn't list any BIOS file for download. It is assumed that the laptop is running the latest production BIOS. BIOS SETUP is set to defaults. Unfortunately, there isn't a BIOS option that specifically controls C-states that is visible to the user.
Created attachment 137821 [details] dmesg, Lenovo S110 w/ Intel Atom N2800, 6-2-2014
Created attachment 137831 [details] acpidump, Lenovo S110 w/ Intel Atom N2800, 2014-06-02
I'm attaching the latest dmesg and acpidump outputs for the desktop with Intel Core 2 Duo E8400. The motherboard, an Asrock G41C-GS, is already up-to-date with the latest BIOS file from the Asrock support site. BIOS SETUP is set to defaults. Unfortunately, there isn't a BIOS option that specifically controls C-states that is visible to the user.
Created attachment 137841 [details] dmesg, desktop w/ Intel Core 2 Duo E8400, 2014-06-02
Created attachment 137851 [details] acpidump, desktop w/ Intel Core 2 Duo E8400, 2014-06-02
Correction: There is a BIOS option for the motherboard, Enhanced Halt State, that is currently set to ENABLED.
Re: desktop box CPU0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (fam: 06, model: 17, stepping: 06) This is a processor released in 2008 DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./G41C-GS, BIOS P1.40 12/06/2013 This is a BIOS dated in 2013. Did this vendor really supply a BIOS for a 5-year old processor? 05Fh 0095 1] _CST Support : E3 [060h 0096 2] C2 Latency : 0065 [062h 0098 2] C3 Latency : 03E9 0x65 is 101 -- telling us that this system does not support ACPI C2 0x3E9 is 1001 -- telling us that this system does not support ACPI C3 _CST support: E3 tells us that the system supports _CST -- though there was no CST in the acpidump you sent. Perhaps you ran an old version of acpidump that doesn't know about dynamic tables. (the latest acpidump is in the linux kernel source tree) or you can copy the files from /sys/firmware/acpi/tables/dynamic/ and attach to this report?
(In reply to Len Brown from comment #27) > Re: desktop box > > CPU0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (fam: 06, model: 17, > stepping: 06) > > This is a processor released in 2008 > > DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./G41C-GS, BIOS P1.40 > 12/06/2013 > > This is a BIOS dated in 2013. > Did this vendor really supply a BIOS for a 5-year old processor? > Yes, please check here: http://www.asrock.com/mb/Intel/G41C-GS/?cat=Download&os=BIOS > > 05Fh 0095 1] _CST Support : E3 > [060h 0096 2] C2 Latency : 0065 > [062h 0098 2] C3 Latency : 03E9 > > 0x65 is 101 -- telling us that this system does not support ACPI C2 > 0x3E9 is 1001 -- telling us that this system does not support ACPI C3 > > _CST support: E3 > tells us that the system supports _CST -- though there was no CST > in the acpidump you sent. Perhaps you ran an old version of acpidump > that doesn't know about dynamic tables. (the latest acpidump is in > the linux kernel source tree) or you can copy the files from > /sys/firmware/acpi/tables/dynamic/ > and attach to this report? This is the output of acpidump -v Intel ACPI Component Architecture ACPI Binary Table Dump Utility version 20140214-64 [Mar 29 2014] Copyright (c) 2000 - 2014 Intel Corporation I'm also attaching SSDT2 and SSDT3 files found in /sys/firmware/acpi/tables/dynamic
Created attachment 137931 [details] files inside /sys/firmware/acpi/tables/dynamic
Re: desktop machine seeing only C1 You've got a modern acpidump, so it already got the tables from /sys/firmware/acpi/tables/dynamic. Per the dmesg, it seems Linux loads a dynamic table for P-states for each CPU, but it doesn't load any for C-states. Further, it appears that the addresses for such tables are dummy: Name (CSDT, Package (0x18) { "CPU0CST ", 0x80000000, 0x80000000, "CPU1CST ", 0x80000000, 0x80000000, So this BIOS doesn't enable more than C1 on this box. If you are able to boot Windows on it and show that Windows sees more than C1, then we have a Linux issue, but it appears that the BIOS is not exporting C-states and Linux is doing the right thing.
re: lenovo s110 [05Fh 0095 1] _CST Support : 85 [060h 0096 2] C2 Latency : 0065 [062h 0098 2] C3 Latency : 03E9 So FADT mode marks C1 and C3 as disabled, at least as running... The SSDT references dynamic SSDTs that suggest they could be for CST: Name (SSDT, Package (0x0C) { "CPU0IST ", 0x7F586C10, 0x000002A7, "APIST ", 0x7F585E10, 0x000001CF, "CPU0CST ", 0x7F584710, 0x000006D5, "APCST ", 0x7F586F10, 0x0000008D }) And Linux loads only the IST ones: [ 0.299882] ACPI: SSDT 7f586c10 002A7 (v01 PmRef Cpu0Ist 00003000 INTL 20100121) [ 0.300537] ACPI: Dynamic OEM Table Load: [ 0.300544] ACPI: SSDT (null) 002A7 (v01 PmRef Cpu0Ist 00003000 INTL 20100121) [ 0.310401] ACPI: SSDT 7f585e10 001CF (v01 PmRef ApIst 00003000 INTL 20100121) [ 0.311100] ACPI: Dynamic OEM Table Load: [ 0.311107] ACPI: SSDT (null) 001CF (v01 PmRef ApIst 00003000 INTL 20100121) Lets take a peak at the ones Linux does not load, please attach these output files: # acpidump -a 0x7F584710 -o CPU0CST.dat # acpidump -a 0x7F586F10 -o APCST.dat
(In reply to Len Brown from comment #30) > Re: desktop machine seeing only C1 > > (...) > > So this BIOS doesn't enable more than C1 on this box. > If you are able to boot Windows on it and show that > Windows sees more than C1, then we have a Linux issue, > but it appears that the BIOS is not exporting C-states > and Linux is doing the right thing. I could see from the system logs on Windows 7 that the OS is only seeing 1 idle state, and, even worse, 0 performance states, 0 throttle states. Would it be feasible to work around the BIOS to enable deeper sleep states on this processor via intel_idle?
Created attachment 139521 [details] APCST.dat and CPU0CST.dat on Lenovo S110
Seems related to https://bugzilla.kernel.org/show_bug.cgi?id=84711
This is exactly a duplicate of bug 84711. Bug closed. *** This bug has been marked as a duplicate of bug 84711 ***