Bug 293711 - hald-addon-cpufreq doesn't scale CPU frequency correctly
hald-addon-cpufreq doesn't scale CPU frequency correctly
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-09-17 15:07 EDT by Stefan Becker
Modified: 2009-01-08 23:53 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-08 23:53:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
HAL cpufreq test script (938 bytes, text/x-python)
2007-11-24 10:15 EST, Stefan Becker
no flags Details

  None (edit)
Description Stefan Becker 2007-09-17 15:07:00 EDT
Description of problem:

After the latest kpowersave update the CPU fan of my laptop gets activated very
frequently, even when the system is idle. When looking at the kpowersave window
I can see that instead of running at the lowest frequency the CPU is running at
the highest frequency almost all the time. It's just thanks to the HALT in idle
mode that the CPU and therefore the CPU fan isn't running full power all the time.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Select "userspace" as cpufreq governor (should be default)
2. Disable cpuspeed service: service cpuspeed stop
3. Start kpowersave and select Dynamic as frequency scheme

Actual results:
See above

Expected results:
kpowersave's dynamic CPU frequency algorithm should behave similar to cpuspeed's
algorithm, ie. CPU should be running at lowest frequency when idle

Additional info:

The behavior of kpowersave has changed with the update. I guess the new version
from svn now implements a user space CPU frequency algorithm which uses
hald-addon-cpufreq to control the CPU frequency. The old version didn't seem to
do anything in that respect.

The combination cpuspeed & hald-addon-cpufreq works fine, ie. they don't
interfere with each other, so I guess hald-addon-cpufreq is just providing an
interface but doesn't have any CPU frequency algorithm itself.
hald-addon-cpufreq & kpowersave and disabled cpuspeed shows the reported wrong

It might be that this is related to the CPU and the related scaling driver used
in my system, i.e. kpowersave's new algorithm doesn't recognize the CPU or the
scaling driver correctly:

# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : mobile AMD Athlon(tm) XP 2200+
stepping        : 1
cpu MHz         : 663.430
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36
mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts fid vid
bogomips        : 1327.53
clflush size    : 32

# ls /sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus     scaling_available_frequencies  scaling_governor
cpuinfo_cur_freq  scaling_available_governors    scaling_max_freq
cpuinfo_max_freq  scaling_cur_freq               scaling_min_freq
cpuinfo_min_freq  scaling_driver                 scaling_setspeed

# cat /sys/devices/system/cpu/cpu0/cpufreq/*
663430 796116 928802 1061488 1194174 1326860 1459546 1592232 1791261
userspace performance

Please note that the above info was taken after I disabled kpowersave and
enabled cpuspeed again, so it shows the CPU running at the lowest frequency again.
Comment 1 Stefan Becker 2007-09-17 16:39:56 EDT
I just noticed that kpowersave controls the CPU frequency the WRONG way around
on my system. Every time the CPU load increases kpowersave DECREASES the CPU
frequency and vice versa! E.g. when I run a compilation job the CPU frequency
goes from 1.8Ghz to 660 Mhz. It goes back to 1.8GHz after the compilation has

I also noticed that kpowersave 7.3 was released a couple of hours ago. I created
a RPM with the new source and tried it: Same results :-/
Comment 2 Stefan Becker 2007-09-18 11:42:24 EDT
Poking around in the kpowersave source code it seems that it is not controlling
the CPU frequency after all. It is just giving hald-addon-cpufreq some parameters:

 if (!dbus_HAL->dbusSystemMethodCall(...
 				     DBUS_TYPE_INT32, &limit,
 if (!dbus_HAL->dbusSystemMethodCall(...
				     DBUS_TYPE_BOOLEAN, &consider,

So the problem is not kpowersave but hald-addon-cpufreq. That would also explain
why the problem continues after I quit kpowersave. Once I kill
hald-addon-cpufreq the CPU frequency goes back to normal.

Changing component to hal.
Comment 3 Stefan Becker 2007-11-10 17:25:45 EST
Retested with F8: still the same problem

Comment 4 David Zeuthen 2007-11-12 12:32:02 EST
I'm not sure why this is assigned to HAL; HAL is only a mechanism, whatever
kpowersave decides to do has nothing to do with HAL.
Comment 5 Stefan Becker 2007-11-12 15:47:53 EST
The problem shows up when you start kpowersave. It then tells the HAL cpufreq
addon what to do (see comment #2). You can even stop kpowersave after that and
HAL cpufreq plugin will continue to set the CPU frequency incorrectly until you
kill it. kpowersave itself does not control the CPU frequency, the HAL cpufreq
addon does.

This has probably been "broken" in HAL all along but it only now became visible
to me when kpowersave was updated to talk to HAL cpufreq.
Comment 6 Stefan Becker 2007-11-24 10:15:37 EST
Created attachment 268031 [details]
HAL cpufreq test script

I've now extracted the relevant code from kpowersave and converted it to a
Python test script.

Test steps:

# ps -ef | fgrep cpu
root	  1700	1661  0 Nov22 ?        00:00:00 /usr/libexec/hald-addon-cpufreq

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
# /home/stefanb/hal_cpufreq_test.py
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
... run some CPU intensive stuff ...
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
... stop CPU intensive stuff ...
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Same now with cpuspeed:

# kill -HUP 1700
# ps -ef | fgrep cpu
# service cpuspeed start
Starting cpuspeed:					   [  OK  ]
# ps -ef | fgrep cpu
root	  7947	   1  0 17:09 ?        00:00:00 cpuspeed -d -p 20 80 -n
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
... run some CPU intensive stuff ...
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
... stop CPU intensive stuff ...
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

So the problem is in hald-addon-cpufreq *UNLESS* you can point out what is
wrong with the way the HAL cpufreq interface is used in kpowersave/my Pyhton
Comment 7 Richard Hughes 2008-05-30 07:43:43 EDT
Does using ondemand make your cpu fan spin less?
Comment 8 Stefan Becker 2008-05-30 07:52:28 EDT
This is a Athlon K6 based system. The only available frequency scaling governors
are "userspace performance" (see above).

In the above test case the CPU fan starts to run full speed a short time after
the frequency shown in scaling_cur_freq changes to 1791261.
Comment 9 Bug Zapper 2008-11-26 02:48:50 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 10 Bug Zapper 2009-01-08 23:53:43 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.