Celeron M530, no frequence scaling

Bug #177646 reported by hmc8
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-cpufreq-applet (Ubuntu)
Invalid
Undecided
Unassigned
linux (Ubuntu)
Invalid
Medium
Andy Whitcroft
linux-meta (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: gnome-cpufreq-applet

Hello,
my brandnew Lapto has a Celeron M530 with 1,73Ghz.
Frequence Scaling is not possible and the cpu has always 1,73Ghz.

A german member of ubuntuusers has written a little patch for it:

http://www.ecarux.de/index.php?option=com_content&task=blogsection&id=12&Itemid=43
Scroll down to " Frequency Scaling für neue Celerons"

*Please* include this patch in hardy!

ProblemType: Bug
Architecture: i386
Date: Thu Dec 20 13:15:44 2007
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/nautilus
Package: nautilus 1:2.20.0-2ubuntu2
PackageArchitecture: i386
ProcCmdline: nautilus --no-default-window --sm-client-id default2
ProcCwd: /home/mutt
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=C
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux ubuntu 2.6.24-2-generic #1 SMP Fri Dec 14 00:02:38 GMT 2007 i686 GNU/Linux

Revision history for this message
hmc8 (hmc8) wrote :
Revision history for this message
Emmanuel Andreu (emmanuel-andreu-deactivatedaccount) wrote :

I have the same CPU on my Lenovo 3000 N200 (0769-A42). Trying to insert p4-clockmod on this m530 gives : FATAL: Error inserting p4_clockmod (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/p4-clockmod.ko): No such device.
Plus, no sensors (thermals and others) can be found by Linux, even with the lm-sensor detection tools, on this CPU. The bug is probably not a "gnome-cpufreq-applet" one, but should be affected to maybe kernel support, acpi... Freq modulation and sensors are OK on Vista, sensors OK on XP but without freq scaling.
The BIOS itself works fine on thermal detection (fan runs OK) but the CPU seems to overheat when fully loaded (I encountered some shutdowns on high temperature).
This bug report (or is it a hardware support request ?) should probably be updated and affected to another package.

Revision history for this message
yannis (yannis-lg) wrote :

Same with a Intel Pentium M 745 ... and hardy alpha 5
This bug was not present in alpha 4 .

Revision history for this message
Johannes Hessellund (osos) wrote :

This is actually a problem in the kernel. Or actually in the p4-clockmod module.

Applying a simple patch solves the scaling issue in p4-clockmod for Celeron M's.

The patch involves only one line.

Please apply this patch in future kernel updates for Hardy.

Revision history for this message
Wesley Velroij (velroy1) wrote :

Is use also new celeron m 540 1,86 and i got the same problem here. So please apply this patch in kernel

Revision history for this message
Matthew Garrett (mjg59) wrote :

Using p4_clockmod will generally not result in any power savings (it merely throttles the CPU without dropping the core voltage, so the power savings are lower than will be obtained by using C states alone), so while this is a valid wishlist bug there's no urgency.

Revision history for this message
Matthew Garrett (mjg59) wrote :

Not a bug in cpufreq-applet

Changed in gnome-cpufreq-applet:
status: New → Invalid
Revision history for this message
Johannes Hessellund (osos) wrote :

Matthew,

Are there any solution to the C-states problem then?
Or any explanation, why the Celeron M 530 and 540 are not scaled?

What will result in power savings for these CPUs?
How do we enable it in Hardy?

Revision history for this message
Matthew Garrett (mjg59) wrote :

Celerons do not support frequency scaling, only throttling. Throttling is a thermal management technique, not a power saving one. The best power savings you'll get are by not using p4_clockmod, or by replacing the machine with one with a full Pentium.

Revision history for this message
Johannes Hessellund (osos) wrote :

According to this spec regarding the Celeron 500 series, covering at least the 540 (not sure about the M 530):
 http://download.intel.com/design/mobile/datashts/31766603.pdf

the architecture does support clock and power control, through the C-states. It seems not to be only a thermal solution, but what do I know!

Is C-states control the throttling/thermal technique you are talking about?
And is C-state handling taken care of, in the current Hardy kernel?

Sorry for my (maybe) stupid questions!

Revision history for this message
Wesley Velroij (velroy1) wrote :

I am making new kernel and hopefull i enabled powersaving opties

Revision history for this message
Wesley Velroij (velroy1) wrote :

I dont know if i did i right but dont wait on me am not a dev.

Revision history for this message
hmc8 (hmc8) wrote :

@M. Garrett: That's not true. After applying the patch you get this:

bash-3.2# cpufreq-info
cpufrequtils 0.4: cpufreq-info (C) Dominik Brodowski 2004
Report errors and bugs to <email address hidden> E-Mail Adresse ist gegen Spam Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können , please.
analyzing CPU 0:
  driver: p4-clockmod
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 217 MHz - 1.73 GHz
  available frequency steps: 217 MHz, 433 MHz, 650 MHz, 867 MHz, 1.08 GHz, 1.30 GHz, 1.52 GHz, 1.73 GHz
  available cpufreq governors: conservative, ondemand, userspace, performance
  current policy: frequency should be within 217 MHz and 1.73 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 217 MHz (asserted by call to hardware).

 bash-3.2# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 530 @ 1.73GHz
stepping : 1
cpu MHz : 216.666
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3461.14
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

Revision history for this message
Wesley Velroij (velroy1) wrote :

How can you add the patch easy to you exsting kernel?? and then set on cpufreq

Revision history for this message
Matthew Garrett (mjg59) wrote :

Yes. If you use p4_clockmod, you can alter the frequency of the processor. However, you cannot alter the voltage. As a result, you can reduce the power consumption of your processor by around a third only by making it take twice as long to do anything. This does not save you power overall.

C states allow the processor to unclock itself and save significant quantities of power by disabling unused portions of the CPU. They are automatically used on Linux, even on the Celeron. However, they can only be entered if the processor is entirely idle. If you use p4_clockmod then your processor will spend more of its time working and less time in the C states. As a result, it will consume more power than if you don't use p4_clockmod.

HMC8: Modern Intel processors only support reducing the core voltage (which can reduce power consumption) if they have "est" in their flags field. Otherwise, it's better to run at full speed in order to allow earlier entry to the C states.

Revision history for this message
Wesley Velroij (velroy1) wrote :

Okay can be true but white cpu freq on celeron the battery last longer so please add the patch in next kernel update,

Revision history for this message
Johannes Hessellund (osos) wrote :

Are you able to document battery usage with and without the patch !?

battery info under: /proc/acpi/battery/BAT0/info

Revision history for this message
Wesley Velroij (velroy1) wrote :

present: yes
design capacity: 4000 mAh
last full capacity: 3829 mAh
battery technology: rechargeable
design voltage: 11100 mV
design capacity warning: 200 mAh
design capacity low: 120 mAh
capacity granularity 1: 264 mAh
capacity granularity 2: 3780 mAh
model number: GC86508SAT0
serial number:
battery type: Lion
OEM info: SANYO

This is without the patch. With patch i can look if i compile the kernel.

Revision history for this message
Johannes Hessellund (osos) wrote :

Sorry my bad....

Your computers power usage is available when running on battery(without ac connected) in

/proc/acpi/battery/BAT0/state

The line called "present rate:"

Revision history for this message
Wesley Velroij (velroy1) wrote :

I can not check with because i need to compile the kernel again. But i can tell from guidance-power-manager that is used cpufreq on low cpu usage 2 a 3 kw less then on performace.

Revision history for this message
Wesley Velroij (velroy1) wrote :

So i apply the patch today and here are the results.

With cpufreq on

present: yes
capacity state: ok
charging state: discharging
present rate: 1307 mA
remaining capacity: 3676 mAh
present voltage: 12029 mV

With NO cpufreq on

present: yes
capacity state: ok
charging state: discharging
present rate: 2046 mA
remaining capacity: 3447 mAh
present voltage: 11953 mV

I hope you will and the patch.

Revision history for this message
Johannes Hessellund (osos) wrote :

Thank you, the results speaks a clear language, power usage dropped 36 % !
I will try to confirm these results, but unfortunately I havent got the time until june.

Matthew, what do you think about the result?

Any chance this patch will be included in the near future?

Revision history for this message
Wesley Velroij (velroy1) wrote :

The result was after pulling the cabel out of it i dont know sure if it realy saves that much.

Revision history for this message
Gerson "fserve" Barreiros (fserve) wrote :

hi guys, i made the new p4-clockmod with patch. (tested with 32bits.)

just copy my attachment and put at

/lib/modules/2.6.24-17-generic/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko

then sudo modprobe p4-clockmod

and look at dmesg

"p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available"

;)

tested with 2.6.24-17 32bits ubuntu on a celeron m550 (@249mhz)

Revision history for this message
LeO (leo-welsch) wrote :

Unfortunately the

sudo modprobe p4-clockmod

works only as long as the computer is not turned off. Is there a way to make this working automatically as well when the computer is turned on? The other question is, if this works as well when logged in as a different user then the Administrator????.

2.6.24-19-generic ubuntu on a celeron m550

Revision history for this message
LeO (leo-welsch) wrote :

I have now tried the patch from Gerson "fserve" Barreiros for the last few days and the system runs instable. I have tried to use either GFreqlet for the panel or via Konsole powernowd. And for both option I recognize that there is a throtteling of the system-tact, but after approx. 30 min. or so, the whole system freeze. Nothing more is possible. If I do not apply the frequence-control, the system runs smooth without much further problems. Since I do not know, which logs could be reviewed after a halt, I cannot provide more information.

Anyhow, currently I refuse usage of the patch. :(

Revision history for this message
Gerson "fserve" Barreiros (fserve) wrote :

>Unfortunately the
>sudo modprobe p4-clockmod
>works only as long as the computer is not turned off. Is there a way to make this working automatically as well when the computer is turned on? The other question is, if this works as well when logged in as a different user then the Administrator????.
>2.6.24-19-generic ubuntu on a celeron m550

-- Try:

echo p4-clockmod | sudo tee -a /etc/modules

>I have now tried the patch from Gerson "fserve" Barreiros for the last few days and the system runs instable. I have tried to use either GFreqlet for the panel or via Konsole powernowd. And for both option I recognize that there is a throtteling of the system-tact, but after approx. 30 min. or so, the whole system freeze. Nothing more is possible. If I do not apply the frequence-control, the system runs smooth without much further problems. Since I do not know, which logs could be reviewed after a halt, I cannot provide more information.

>Anyhow, currently I refuse usage of the patch. :(

i think all logs can be reviewed after a halt, just check syslog

here on my system using 2.6.24-19 still ok, i'm using ondemand as scaling_governor.

Revision history for this message
LeO (leo-zen) wrote :

I am now running for the changed options for about one week and it seems they work. The previous experienced problems I would say, are related to two instances of monitoring CPU-frequency. This was manly due to the fact, that the standard Frequence-panel required a restart, to display as well the options.

Although I have another serious problem which freeze my compy regularly, I do not assume they are related. (Bug ID 248505).

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
LeO (leo-welsch) wrote :

uname -r ==> 2.6.27-2-generic

The Live-CD launches properly and I could add the Frequency-Panel to my Panels. But there there is no possiblity to change the frequnency scaling by default ==> this is not fixed in the 8.10 :(

Revision history for this message
spuk (gustavodn) wrote :

p4-clockmod won't reduce clock, the CPU just stays idle during N out of M clock cycles. The power consumption during those cycles is just as if the CPU was normally idle, the clock modulation will just "force" it to be idle.

p4-clockmod is unlikely to reduce power consumption unless the CPU load is normally above the throttle (i.e. CPU load at 50%, throttle at 25%), that kind of cases are the ones where p4-clockmod would help the battery last longer, but it is unlikely in a current desktop system. The more common situation will be CPU load under 10%, while the minimum throttle is 12% (or higher, in case of some bugged CPUs which can't use the lowest throttles), so it wouldn't really help.

Furthermore, I think it is possible that using a clock governor other than "performance" (ie. ondemand) with p4-clockmod will still worsen the performance, if it makes the clock flutuate too much, making the CPU waste time switching the throttling state.

Revision history for this message
Marcus Sundman (sundman) wrote :

Since this is not (yet) fixed in intrepid I used the patch above and compiled a new p4-clockmod and packaged it in a deb that won't overwrite the original, but merely dpkg-divert it until the deb is removed:
http://sundman.iki.fi/ubuntu/intrepid/celeronm-cpufreq-2.6.27_1_i386.deb

Andy Whitcroft (apw)
Changed in linux:
assignee: ubuntu-kernel-team → apw
status: Triaged → In Progress
Changed in linux-meta:
status: New → Invalid
Revision history for this message
Andy Whitcroft (apw) wrote :

CPU throttling (as opposed to later frequency/power scaling) is not expected to give us any particular power savings on CPUs supporting the C2 idles states, which the ones mentioned here should support. Obviously at any instant there may be a power saving if the cpu is running at 50% throttling as compared to 0% throttling if the CPU is under load, the maximum power the CPU can consume is constrained but so is its throughput; thus andy specific task will take longer and consume the same power overall. As a general rule any machine being used for interactive or bursty work is idle nearly all the time, and when it is idle it should be automatically placed into C2 state to conserve power. As power consumption in C2 is the same as power consumption during the 'idle' cycles introduced by throttling, overall power consumption for any bursty task from start to completion should be the same. Therefore throttling _should_ never be a benefit. Below are some references to some background I found when researching this bug:

 https://kerneltrap.org/mailarchive/linux-kernel/2008/1/18/581756
 http://article.gmane.org/gmane.linux.kernel.cpufreq/3497
 https://kerneltrap.org/mailarchive/linux-kernel/2008/1/20/585998

@kurosaki_ichigo

You pasted in some battery consumption information when using frequency throttling, which show about a 36% drop in power consumption but you do not indicate either the throtteling level used nor the test load you were running on it. Do you still have those details?

Andy Whitcroft (apw)
Changed in linux:
status: In Progress → Incomplete
Revision history for this message
Andy Whitcroft (apw) wrote :

We are closing this bug report because it lacks the information we need
to investigate the problem, as described in the previous comments.
Please reopen it if you can give us the missing information, and don't
hesitate to submit bug reports in the future. To reopen the bug report
you can click on the current status, under the Status column, and change
the Status back to "New". Thanks again!

Changed in linux:
status: Incomplete → Invalid
Revision history for this message
Wesley Velroij (velroy1) wrote :

It has more off enough information, but I am not sure if it would really safe energy.

Revision history for this message
LeO (leo-zen) wrote :

Pehaps it would not save energy for the CPU. But I assume the CPU does not heat that much when running with 500 MHZ or 1 GHZ instead of 2 GHZ. So, perhaps it does not save the CPU-power consumptions, but it saves the cooling devices + it saves on the long term the material. Saving the cooling devices on a Laptop means in most of the cases to avoid fan-activity ==> no power consumption on the fan => power saving.

I see it more or less the side-effect a reduced CPU-frequ has on the overall system. AND therefore I would like to have it enabled.

Revision history for this message
Andy Whitcroft (apw) wrote : Re: [Bug 177646] Re: Celeron M530, no frequence scaling

On Thu, Jan 15, 2009 at 05:38:26PM -0000, Wesley Velroij wrote:
> It has more off enough information, but I am not sure if it would really
> safe energy.

It has information to prove the option is not enabled. The option is
not enabled because it should be of no help. The CPU will be in the same
states for the same length of time overall though possibly in a slightly
different distribution, therefore power consumption is not modified.
I linked to the discussions of why how the kernel uses the various CPU
states, and how this option is not a power management option. There is
even discussion there of how enabling this would have a detremental
effect on power consumption in some use models.

The only feedback on the bug which might show an actual reduction in power
consumption was not described in enough detail to show whether the power
consumption was being measured in a truly comparible way, ie. was it an
instantaneous measurement or over the whole period of the task. The key
being overall power consume during the whole task. It was that information
which we were waiting for, and was not forthcoming. Therefore we are
in a position where the is no information to show this is a benefit,
and much to how it would likely be zero and even a negative impact.

That is what led to the closure lacking information.

Revision history for this message
Andy Whitcroft (apw) wrote :

On Fri, Jan 16, 2009 at 10:34:38AM -0000, LeO wrote:
> Pehaps it would not save energy for the CPU. But I assume the CPU does
> not heat that much when running with 500 MHZ or 1 GHZ instead of 2 GHZ.
> So, perhaps it does not save the CPU-power consumptions, but it saves
> the cooling devices + it saves on the long term the material. Saving the
> cooling devices on a Laptop means in most of the cases to avoid fan-
> activity ==> no power consumption on the fan => power saving.
>
> I see it more or less the side-effect a reduced CPU-frequ has on the
> overall system. AND therefore I would like to have it enabled.

The problem is that the CPU still has to perform the same number of
cycles at full speed to run any task it is asked to perform, and those
will consume the same amount of energy whether they are done together or
spread out. There is evidence that the overall energy cost is actually
higher when switching in and out of the sleeping state really often
(which is what occurs when this mode is enabled) and thus more energy is
consumed and heat dissipated. We also need to consider the temperature
as seen at the heat sink is majorly divorced from the temperature profile
of the chip surface itself.

What I am trying to say here is that it is not at all obvious that enabling
this is a good thing. There is a lot of "I feel it will be better"
sentiment, mostly as they are running without a power control module and
with one "must be better", but no direct evidence that it is better, and
much comment from those with direct access to the manufacturers saying
the opposite.

To make any progress on this someone would have to take the time to do a
fully measured (power consumption at the wall) comparison on a sensible
workload for the machine and present those results. Which is what one
commenter seemed to have done but had not explained how the results were
generated to allow verification.

Revision history for this message
Wesley Velroij (velroy1) wrote :

Just adding the patch to kernel is to much to ask? I can't test anymore because if i apply the patch the rest of my kernel would be messed up. Ubuntu has some much testing, why not test it? Release a Kernel for testers and voila?

Revision history for this message
Andy Whitcroft (apw) wrote :

On Fri, Jan 16, 2009 at 01:08:32PM -0000, Wesley Velroij wrote:
> Just adding the patch to kernel is to much to ask? I can't test anymore
> because if i apply the patch the rest of my kernel would be messed up.
> Ubuntu has some much testing, why not test it? Release a Kernel for
> testers and voila?

Well its a non-zero cost, in time if nothing else, to build test kernels
and ship them. If people are going to activly test these kerenls then I can
produce some. I do not have access to hardware to test myself.

Revision history for this message
LeO (leo-zen) wrote :

about running tests: I volunteer to do so, but I need to know what should be collected and how. Namely running Ubuntu would not much bring, as long as I do not know which app at which state and switching forth and back, etc.etc.

Somehow I agree with 'There is a lot of "I feel it will be better" sentiment' and that's the reason why I can make some kind of test-procedure. I have currently NOT installed the govenor, due to some other reasons. Can anybody guide me through some kind of test-parcour which should be done to have finally hard facts and not much more is missing.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.