Bug 293711
Summary: | hald-addon-cpufreq doesn't scale CPU frequency correctly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stefan Becker <chemobejk> | ||||
Component: | hal | Assignee: | Dennis Gilmore <dennis> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 8 | CC: | davidz, dennis, rdieter, richard | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-01-09 04:53:43 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Stefan Becker
2007-09-17 19:07:00 UTC
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. |