See Kernel Bug #14771 and Gentoo Bug #287463.

The "ondemand" scheduler was changed circa Linux 2.6.30 so it no longer works correctly.  (Patch to p4-clockmod.c is attached to the Gentoo bug report).

Kernel developers seem to believe that everyone is running Intel CPU's with "Enhanced" SpeedStep capabilities with an ACPI BIOS which has power control (_PCT) abilities.  If either are unavailable then the acpi-cpufreq driver is unlikely to work.  For the "ondemand" scheduler to work correctly it needs to be fixed so detects non-enhanced Intel SpeedStep processors *or* non-_PCT enabled ACPI BIOS conditions and reverts the ondemand scheduler that found prior to Linux 2.6.30 (though changing p4-clockmod.c: policy->cpuinfo.transition_latency to the old value -- or some other modifications).

In your case I think the Celeron may have "Enhanced" SpeedStep capabilities, but if the HP ACPI BIOS doesn't have the "_PCT" controls the acpi-cpufreq functions are unlikely to work.  You need to build the kernel with both acpi-cpufreq and ondemand as modules and flip back and forth between them with ACPI debugging enabled.  If you attempt to modprobe acpi-cpufreq and get "No such device" (ENODEV) it is likely your BIOS is the source of the problem.

Thanks for the quick tip, but I have found multiple references over the inet, complaining about broken support on this kinda of CPU. Is it possible that all of them had a broken bios? Initially, I assumed that this cpu is quite new and kernels developers didn't have time to add support for it

Hi,

I can confirm the same problem on a Packard Bell Easynote Butterfly XS with the same processor. I've tried running kernel-2.6.35-rc3 (x86_64) but the problem persisted. The cpu runs quite hot for a processor of this type: 46-51°C (idle - normal use).

Booting with kernel parameter "cpufreq.debug=7" gave the following relevant information in dmesg:

acpi-cpufreq: acpi_cpufreq_init
acpi-cpufreq: acpi_cpufreq_early_init
cpufreq-core: trying to register driver acpi-cpufreq
cpufreq-core: adding CPU 0
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
acpi-cpufreq: No P-States
cpufreq-core: initialization failed
cpufreq-core: adding CPU 1
acpi-cpufreq: acpi_cpufreq_cpu_init
cpufreq-core: CPU 1: _PPC is 0 - frequency not limited
acpi-cpufreq: No P-States
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver acpi-cpufreq
cpufreq-core: unregistering CPU 0
cpufreq-core: unregistering CPU 1
cpufreq-core: trying to register driver p4-clockmod
cpufreq-core: adding CPU 0
speedstep-lib: x86: 6, model: 17
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition of frequency scaling. You should use that instead of p4-clockmod, if possible.
cpufreq-core: initialization failed
cpufreq-core: adding CPU 1
speedstep-lib: x86: 6, model: 17
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition of frequency scaling. You should use that instead of p4-clockmod, if possible.
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver p4-clockmod
cpufreq-core: unregistering CPU 0
cpufreq-core: unregistering CPU 1

This problem is probably related to https://bugzilla.kernel.org/show_bug.cgi?id=15377 (same cpu, no P-states in powertop).

Thanks for any help.

> I assumed that this cpu is quite new and kernels developers didn't have
> time to add support for it
This should more read more like:
CPU is quite new and BIOS developers didn't have time to add support for it...

Best you:
  - Check that the latest BIOS running
  - Check BIOS settings for power management, speedstep, cpufreq or related
    options you can enable
  - If things still do not work, please attach acpidump and dmidecode.

How old are these machines about? HP cares about Linux support and chances that they add cpufreq support to their BIOSes if it makes sense aren't that bad if these are recent machines.

Because there are several reports:
Please check whether you have the "est" flag in /proc/cpuinfo showing up.
cpuinfo from the reporter has this bit set, others may have not.
Their CPUs simply do not support CPU frequency scaling then.

Created attachment 27016 [details]
acpidump

Created attachment 27017 [details]
dmidecode

Afaik the BIOS is pretty new so is the laptop. I am pretty sure it is a brand new model ( 2-3 months old )

I 've seen several reports over the inet complaining about missing cpufreq support on this CPU

http://software.intel.com/en-us/articles/enhanced-intel-speedstepr-technology-and-demand-based-switching-on-linux/ ( look @comments )

And yes, my CPU has est flag on /proc/cpuinfo

Created attachment 27032 [details]
dmidecode PB

Created attachment 27033 [details]
acpidump PB

AFAIK the PB notebook was introduced in Q1 2010, the newest BIOS is installed.
As it has the same processor as the HP, the "est" flag in /proc/cpuinfo is present.

This is an Ultra low voltage processor, which should help give these laptops up to 8 hours of battery life. Sadly, no frequency scaling means a 25% or higher penalty in battery life.

This is a link to the Intel specifications page, which includes a link to the data-sheet (was updated for this CPU): http://ark.intel.com/Product.aspx?id=42779

Hi,

I am experiencing a similar problem with a Thinkpad X200s laptop (CPU is the same -- SU2300, kernel version 2.6.34.1) with the latest BIOS version. Acpi-thinkpad module produces exactly the same output in dmesg as in comment #3. The CPU has est flag in /proc/cpuinfo indeed.

And there is also an _OSI condition is DSDT, kernel writes in dmesg:

        ACPI: BIOS _OSI(Linux) query ignored

during boot.

Do you need any additional information to address this bug? Just tried 2.6.36 and the problem is still there

Sorry, I forgot about this one.
There was a thread about this CPU type on the cpufreq list recently:
http://www.spinics.net/lists/cpufreq/msg01764.html

It came out this type of CPU is not speedstep capable, but is still exporting EST CPU capability (compare with flags /proc/cpuinfo).
You might want to verify with the Intel CPU sheet the guy found.

This one should get closed.
I close this one documented, others might want to read it up again.

This shiould not be closed as an "undicumemented bug".  The machine is a
standard HP Pavilion A630N machine (presumably which hundreds of thousands
were manufactured in the 2003-2005 time frame).

In monitoring the Gentoo bug framework I am aware that there are laptops
being manufactured to date (2010) which contain Bios which do not contain
the proper code to  properly inform about the BIOS capabilities.

In short there are still machines which exist out there which WILL NOT
PERFORM properly on what ACPI code is supposed to exisit.  Because it
doesn't exist or cannot be programmed into the machines.   The P4-clockmod
change was/is wrong -- the P4 clockmod driver worked fine for these machines
before the "correction"  I have a machine which works fine backing down to
1.75 GHz or even 750 Mhz.   And I can watch the power consumption decrease
on a Watt-Meter which the machine is plugged into.

Though I am running a gentoo-2.6.35-r10 kernel (whiich I presume is roughly
equivalent to the final release of 2.6.35.   The p4-clockmod, e.g.
arch/x86/kernel/cpu/cpufreq/p4-clockmod.c

is backtracked to ~the 2.6.28 release (or perhaps somehat later)  Because
that is the release which worked on these machines.  Subsequent releases do
not allow P4 clockmod control and are therefore worthless.  There are two
dividing lines -- some people want their machine to be responsive -- and
that may have prompted the change in p4-clockmod.c  And there are others who
may have reasons to leave their computers on (such as to provide web
services)  who may desire minimal CPU/power consumption at all times.   The
current p4-clockmod.c situation prevents that and that is why I am forced to
run an older instantiation of that driver.

It is not a problem which can be resolved by throwing out the older or
un-upgraded (in terms of BIOS capabilities with respect to ACPI).  The
proper response is for Linux to determine if the machine does have advanced
ACPI control capanilities -- and if it does not allow for old-style P4
clockmod fallback..

Because that is what works and it should not be a Linux position to force
people into less than 5 y.o. machines.  p4-clocmod.c used to work perfectly
in reducing power consumption.  It currently does not.  Thus in the current
release of Linux it cannot be viewed as being "green".

On Fri, Jun 25, 2010 at 5:02 AM, <bugzilla-daemon@bugzilla.kernel.org>wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=16072
>
> --- Comment #2 from Markos Chandras <hwoarang@gentoo.org>  2010-06-25
> 09:01:42 ---
> Thanks for the quick tip, but I have found multiple references over the
> inet,
> complaining about broken support on this kinda of CPU. Is it possible that
> all
> of them had a broken bios? Initially, I assumed that this cpu is quite new
> and
> kernels developers didn't have time to add support for it
>

Markos, the CPU is very old (~5+ years).  There are still CPU/BIOS
combinations wch may be coming out which do not properly support the ACPI
power saving options [1] -- and thus one must fall back on the old
p4-clockmod power saving features.  Which did indead work and should not be
effectively disabled as has been the case with more recent releases of
Linux.

Please feel free to contact me for the specific modiification in
p4-clockmod.c which should be removed in order to provide the normal power
saving features.

Best,
Robert

1. It is a very complex situation in terms of what the CPUs are capable of
and what the BIOS is capable of (in terms of managing power conservation).
 In terms of my current read of the Linux code these are in two separate
realms from a development standpoint.  In an ideal world everything would be
going through ACPI and it would manage power use.  In reality that world
does not exist and one should be able to deal with it.  Thus problems with
p4-clockmod.c.

I am really sad to see this bug closed as, apparently, CANTFIX. Rober, can you please attach a working diff of p4-clockmod.c based on the old kernel so I can take advantage of it and save the battery of my *brand new* netbook? Thank you

Sigh, a p4_clockmod discussion again.
I promised myself to stay out of those, but as you provide quite some wrong information let's clear some things up:

> This shiould not be closed as an "undicumemented bug".  The machine is a
> standard HP Pavilion A630N machine (presumably which hundreds of thousands
> were manufactured in the 2003-2005 time frame).
Which does not support CPU frequency scaling, where is the problem?
The CPU itself simply cannot do it.

> In monitoring the Gentoo bug framework I am aware that there are laptops
> being manufactured to date (2010) which contain Bios which do not contain
> the proper code to  properly inform about the BIOS capabilities.
This has nothing to do with BIOS capabilities.

> There are two dividing lines -- some people want their machine to be
> responsive -- and that may have prompted the change in p4-clockmod.c
This high transition latency will cause that you cannot properly work with it.
It may not be that bad if you use it as a server without user interaction, but also there p4_clockmod will not save any/much power, see below.

> And I can watch the power consumption decrease on a Watt-Meter which the
> machine is plugged into.
How much is this for a totally idle system?
Please try again, I do not believe this.

Hmm, this machine does not even support C2...

Still I doubt you gain any/much power consumption with p4_clockmod.
Can you do some checks please if you still have the power meter and measure power consumption if:
  1) p4_clockmod not used and machine is as idle as possible
     (top, kill some processes if necessary)
  2) p4_clockmod is used and machine is as idle as possible
     (top, kill some processes if necessary).
  3) Fully utilized CPU (do "cat /dev/zero >/dev/null &" two or three times and
     kill it again after measuring) with p4_clockmod unused
  4) Fully utilized CPU (do "cat /dev/zero >/dev/null &" two or three times and
     kill it again after measuring) with p4_clockmod used
  5) You should see such a line in dmesg:
     "using mwait in idle threads"
     If this is the case try: idle=halt boot param
     and measure the same as done in 1. (double check that the message in dmesg
     disappeared).

Same sentiment here (sadness) as expressed by Markos Chandras in Comment #17.

The CPU is clearly capable of frequency scaling (and voltage scaling).

Please consider the following:
> Comment #14
> It came out this type of CPU is not speedstep capable
Somewhat misleading: the CPU is "Enhanced Intel SpeedStep® Technology" capable, and should (imo) be handled by the acpi-cpufreq driver. 

> You might want to verify with the Intel CPU sheet the guy found.
I did: please see for yourself at http://www.intel.com/design/mobile/datashts/321111.pdf

> Comment #15
> The machine is a standard HP Pavilion A630N machine
Incorrect: see discription of bug: "[HP Pavilion dm1-1110ev] Cpufreq doesn't work at all ( Intel Celeron U2300 )".  AFAIK this notebook was introduced in Q1 2010. (As were many other notebooks using this CPU)

> Comment #16
> Markos, the CPU is very old (~5+ years). 
Incorrect: launch date of this CPU was Q3 '09; please see: http://ark.intel.com/Product.aspx?id=42779
These CPU's are still being sold/implemented.

> Comment #18
> Sigh, a p4_clockmod discussion again.
Yes, I think the correct discussion should mostly be about acpi-cpufreq.

But just to make certain: in case of overheating, where does linux control the thermal protection of these CPU's? Especially now, WITHOUT drivers?  If the answer here is p4_clockmod (or acpi-cpufreq), one might even think about raising the importance of this bug, considering the potential overheating isues, which are of course not uncommon in notebooks.

>  machine is a
> > standard HP Pavilion A630N machine (presumably which hundreds of thousands
> > were manufactured in the 2003-2005 time frame).
> Which does not support CPU frequency scaling, where is the problem?
> The CPU itself simply cannot do it.
I hope it is clear by now that the SU2300 in the HP Pavilion dm1-1110ev *DOES* support CPU frequency scaling.

> Hmm, this machine does not even support C2...
Luckily for us, the SU2300 supports C1/AutoHALT, C1/MWAIT, C2, C3 and C4, otherwise we would all (presumably) be forced to go back to running Windows on our notebooks.

I hope this bug can be truly resolved, if not, can anyone point me to the  "documentation" with which to "Resolve" this bug, as mentioned in the bug "Status"?

Thanks.

I am not that familiar with the whole concept, but it looks quite strange to me how is it possible for a brand new *netbook* to have a CPU that does not support frequency scaling ( It is speedstep capable according to the docs ). Sad thing I never tried running windows on it so verify whether it works or not. Either HP has failed really bad or I don't know...

After a deeper look into the link provided by Thomas Renninger in Comment #14, and into the datasheet (both of which I should have done in the first place instead of skimming them, sorry for that), it's clear that an important point is the reference to the datasheet, page 30, note 10, which states: "SU2300 processor operates at same core frequency in HFM and LFM" (HFM = Highest Frequency Mode, LFM = Lowest Frequency Mode).  *If* the processor doesn't have a Super Low Frequency Mode (SuperLFM) as stated on page 26 of the datasheet (not really clear), the processor would indeed run at only one frequency.  So it looks like "Enhanced Intel SpeedStep Technology" doesn't automatically imply frequency scaling.

Without SuperLFM, voltage scaling and/or C-states seem to be the best candidates to explain why battery life under Windows was longer than under Linux (but I'm not the expert here).

The question in my previous comment about thermal management in situations where one is not able to load p4-clockmod as a "driver of last resort", stems from the following remark at https://patchwork.kernel.org/patch/7786/ and similar comments elsewhere:
> This is one reason why in .30 the user interface for p4-clockmod is disabled.
> It'll only get throttled when ACPI goes into OMG I'M OVERHEATING mode,
> and ramp back up once it cools off.

> But just to make certain: in case of overheating, where does linux control
> the
> thermal protection of these CPU's? Especially now, WITHOUT drivers?
There is for example a HW based thermal protection.
The HW will throttle (same technique as p4_clockmod) automatically and send a MCE (Machine Check Exception) to inform the user.
Compare with:
arch/x86/kernel/cpu/mcheck/therm_throt.c
Even if this should not be implemented, the CPU will always have a "switch off hard" mechanism in case of not working or missing fans and similar.

> If the
> answer here is p4_clockmod (or acpi-cpufreq), one might even think about
> raising the importance of this bug, considering the potential overheating
> isues, which are of course not uncommon in notebooks.
As it's not only HP, but several vendors (every?) showing this issue with this specific CPU model, I expect it's working as designed.

Thomas, you should have such a P4 machine plugged into a watt-meter as I currently have.  I am (with the kernel modified back to the old p4-clockmod driver) able to detect a significant power savings as the machine scales itself back from 2.8 Ghz to lesser speed power savings [1].

p4-clockmod, as distributed prior to ~2.6.30, *did* work, in at least lowering power consumption when it did not need to be running at 2.8GHz (which on my machine might be only 2-4 hours/day).  Mucking with the BIOS to add "real" ACPI support for reduced power consumption (if the CPU can even support it) is way beyond the capabilities of most users of Linux.

I think the problem is that some kernel developer didn't like the responsiveness of  a machine using p4-clockmod and changed the timing which allowed it to work quite effectively on many/most desktop machines [2].

Its simple for me -- I just change the code back to what worked when I upgrade kernels.  But unless you are comfortable hacking the kernel (not something I consider likely with most Ubuntu users) that is difficult.

Now if the kernel developers would like to release BIOS code for a HP Pavilion with a Pentium IV Prescott CPU which *does* support acpi-cpufreq and no longer generates the message: "cpufreq-core: initialization failed" then I would be willing to consider testing it.

1. The power savings dropping from 2.8 GHz to 350 MHz is 144 to 109 W or nearly 24%.
2. This is spite of the fact that p4-clockmod has a variety of information/adjustment params in /sys/devices/system/cpu/cpu0/cpufreq which could be set to manage the responsiveness of the machine for various workloads [3].  It seems to be a case of using a sledge-hammer to fix something that could have been fixed with a jeweler's screwdriver.
3. Which appear to be undocumented.  So unless you know how to read the source code you cannot "tune" the machine easily.

Robert: Please stop writing wrong assumptions you claim to know for sure. Also only providing half information is nearly as bad as writing wrong ones.
> The power savings dropping from 2.8 GHz to 350 MHz is 144 to 109 W or nearly
> 24%.
I expect this is when the CPU is fully utilized?
The fact that you missed out some measures, smells like you do not like the data, right?
But this bug is about something totally else, please open a new bug, add me to CC and attach all info requested in comment #18. This is not about compiling a kernel, it's simply measuring with a reboot in between, it doesn't take long...


For this very specific CPU this is about, I asked people who may have an idea, but did not get an answer yet. Until now I expect freq switching is not supported. But as deep C-states are, it's not that bad, you want to sleep as soon as possible anyway.