Skip to contentSkip to conversation

Cpufreq doesn't work at all ( Intel Celeron U2300 )

Bug 16072 [email protected] 1 participant 14 messages Aug 2, 2010 – Jul 30, 2011 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=16072

Kostya Stopani <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #12 from Kostya Stopani <[email protected]> 2010-08-02 18:56:35 --- 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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#2 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #13 from Markos Chandras <[email protected]> 2010-10-22 15:33:39 --- Do you need any additional information to address this bug? Just tried 2.6.36 and the problem is still there

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#3 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

Thomas Renninger <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |DOCUMENTED

--- Comment #14 from Thomas Renninger <[email protected]> 2010-10-22 19:37:18 --- 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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#4 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #15 from Robert Bradbury <[email protected]> 2010-10-22 21:09:24 --- 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".

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#5 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #16 from Robert Bradbury <[email protected]> 2010-10-22 21:48:19 ---

Quoted 12 lines · On Fri, Jun 25, 2010 at 5:02 AM, <[email protected]>wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #2 from Markos Chandras <[email protected]> 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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#6 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #17 from Markos Chandras <[email protected]> 2010-10-22 21:59:15 --- 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

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#7 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #18 from Thomas Renninger <[email protected]> 2010-10-22 23:52:22 --- 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:

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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).

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#8 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #19 from Patrick Viane <[email protected]> 2010-10-23 06:03:16 --- 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:

Quoted 2 lines

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.

Quoted 1 line

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

Quoted 2 lines

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)

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 5 lines

machine is a

Quoted 2 lines

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.

Quoted 1 line

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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#9 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #20 from Markos Chandras <[email protected]> 2010-10-23 11:28:13 --- 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...

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#10 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #21 from Patrick Viane <[email protected]> 2010-10-24 10:03:34 --- 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:

Quoted 3 lines

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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#11 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #22 from Thomas Renninger <[email protected]> 2010-10-24 23:10:02 ---

Quoted 2 lines

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.

Quoted 4 lines

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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#12 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #23 from Robert Bradbury <[email protected]> 2010-10-25 17:33:51 --- 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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#13 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

--- Comment #24 from Thomas Renninger <[email protected]> 2010-10-28 15:30:57 ---
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.

Quoted 2 lines

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.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#14 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=16072

Len Brown <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|RESOLVED                    |CLOSED
                 CC|                            |[email protected]
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.