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): kpowersave-0.7.3-0.2svn20070828.fc7 hal-0.5.9-8.fc7 hal-info-20070516-2.fc7 hal-libs-0.5.9-8.fc7 How reproducible: Always 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 behavior. 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/* 0 663430 1791261 663430 663430 796116 928802 1061488 1194174 1326860 1459546 1592232 1791261 userspace performance 663430 powernow-k7 userspace 1791261 663430 663430 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.
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 finished. 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 :-/
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(... "SetCPUFreqPerformance", DBUS_TYPE_INT32, &limit, if (!dbus_HAL->dbusSystemMethodCall(... "SetCPUFreqConsiderNice", 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.
Retested with F8: still the same problem hal-info-20071030-1.fc8 hal-0.5.10-1.fc8 hal-libs-0.5.10-1.fc8 kpowersave-0.7.3-0.2svn20070828.fc8
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.
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.
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 1791261 # /home/stefanb/hal_cpufreq_test.py None None None # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1791261 ... run some CPU intensive stuff ... # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 663430 ... stop CPU intensive stuff ... # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1791261 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 663430 ... run some CPU intensive stuff ... # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1791261 ... stop CPU intensive stuff ... # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 663430 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 script.
Does using ondemand make your cpu fan spin less?
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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.