Red Hat Bugzilla – Bug 505837
cpuspeed daemon fails to start at boot time on system using p4-clockmod
Last modified: 2013-01-10 03:00:23 EST
Description of problem: Setting cpufreq governor from "GOVERNOR=" to "GOVERNOR=ondemand" in file /etc/sysconfig/cpuspeed has no effect on a system supporting "P4/Xeon(TM) CPU On-Demand Clock Modulation" after booting the system unless service "cpuspeed" is manually restarted. Version-Release number of selected component (if applicable): cpuspeed-1.5-6.fc11.i586 How reproducible: Always. Steps to Reproduce: 1. Set "GOVERNOR=ondemand" in file /etc/sysconfig/cpuspeed. 2. Restart system. Actual results: System remains at maximum frequency. Expected results: System modulates frequency dynamically. Additional info: - SMOLT hardware profile of affected system is available at http://smolt.fedoraproject.org/client/show_all/pub_ed9722d3-450a-4075-8c5b-7383b30227ec - It actually seems that service cpuspeed is not started at all when the system boots up. After the system start-up has completed, one obtains: # chkconfig --list cpuspeed cpuspeed 0:Off 1:On 2:On 3:On 4:On 5:On 6:Off # service cpuspeed status p4-clockmod passive cooling is enabled # service cpuspeed start WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. Enabling ondemand cpu frequency scaling: [ OK ] At this point, the CPU frequency actually is handled according to the config file prescribing policy "ondemand".
Loading module "p4-clockmod" manually at runlevel 1 or replacing "DRIVER=" by "DRIVER=p4-clockmod" in file /etc/sysconfig/cpuspeed allows cpuspeed to start up correctly and modulate the CPU frequency as expected without starting service "cpuspeed". Since module "p4-clockmod" got loaded before, too, it got probably loaded at a later time than now, thus, too late for daemon "cpuspeed" to start up properly.
(In reply to comment #1) > Loading module "p4-clockmod" manually at runlevel 1 or replacing "DRIVER=" by > "DRIVER=p4-clockmod" in file /etc/sysconfig/cpuspeed allows cpuspeed to start > up correctly No, it actually allows it to start up INcorrectly. :) Check out the initscript snippet: if [ ! -d ${cpu0freqd} -a "$cpu_vendor" == GenuineIntel ]; then # last-ditch effort for Intel proc boxes, try our neutered p4-clockmod # to get at least passive cooling support (no clock changes) /sbin/modprobe p4-clockmod 2> /dev/null if [ -d ${cpu0freqd} ]; then echo -n "Enabling p4-clockmod driver (passive cooling only): " success; echo return 0 else /sbin/modprobe -r p4-clockmod 2> /dev/null fi fi > and modulate the CPU frequency as expected without starting > service "cpuspeed". The p4-clockmod driver does NOT actually change processor frequency, it just twiddles with the clock and inserts idle waits. This subject has been beaten to death on a number of lists already. There's a link to some of the discussion in /etc/sysconfig/cpuspeed, iirc. > Since module "p4-clockmod" got loaded before, too, it got probably loaded at a > later time than now, thus, too late for daemon "cpuspeed" to start up properly. If you set "DRIVER=p4-clockmod", it bypasses the above snippet that bails after loading the module, and you go through to the governor setup portion. Something is definitely slightly off here, we ought to probably fall through if you set GOVERNOR by hand so you don't have to also set DRIVER, but ultimately, the default behavior is the intended behavior for p4-clockmod systems.
Whoops, link isn't there anymore, here it is: http://lkml.org/lkml/2006/2/25/84 Basically, doing ondemand w/p4-clockmod actually wastes more power in typical usage, since there's no actual freq scaling, only throttling.
This has been discussed at length, right, and the p4-clockmod module was actually removed from the Fedora kernels for a while. However it has since been ressurrected, and thus, it is expected to be supported by cpuspeed. Users who dislike this feature can simply switch off the cpuspeed service.
(In reply to comment #4) > This has been discussed at length, right, and the p4-clockmod module was > actually removed from the Fedora kernels for a while. However it has since been > ressurrected, and thus, it is expected to be supported by cpuspeed. No, its really not. Its expected to provide passive cooling only, as noted in the initscript.
Running ondemand with p4-clockmod introduces noticable latency on many systems and provides no power saving benefit. The default behaviour of not enabling it without user intervention is correct.
I've patched up the initscript so that only specifying governor in the config w/o a driver will let you do p4-clockmod + whatever governor, but we're going to stick with the current setup for the default case.
cpuspeed-1.5-8.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/cpuspeed-1.5-8.fc11
cpuspeed-1.5-8.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
After uninstalling package cpuspeed, removing /etc/sysconfig/cpuspeed.rpmsave, installing cpuspeed-1.5-8.fc11, setting GOVERNOR to ONDEMAND and rebooting the system, the behaviour is exactly as before, namely the frequency remains the maximum frequency. Only after setting DRIVER to p4-clockmodm, too, and restarting service cpuspeed, frequency scaling is actually enabled.
Yeah, I screwed the pooch on that update... The test wasn't in the right place, and it wasn't actually entirely viable. Should have tested more. :\ Fixed fix coming in a sec.
cpuspeed-1.5-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/cpuspeed-1.5-9.fc11
After uninstalling package cpuspeed, removing /etc/sysconfig/cpuspeed.rpmsave, installing cpuspeed-1.5-9.fc11, setting GOVERNOR to ONDEMAND and rebooting the system, the behaviour is exactly as before, namely the frequency remains the maximum frequency. Only after setting DRIVER to p4-clockmod, too, and restarting service cpuspeed, frequency scaling is actually enabled.
Okay, I officially fail. Before I push anything else out, I'm going to get an actual p4-clockmod system to test on...
cpuspeed-1.5-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Please give cpuspeed-1.5-10.fc12 a spin, I've actually tested this time on a real live p4-clockmod system, and so far as I can tell, it now behaves as it was intended to ~3 revisions ago now. :)
cpuspeed-1.5-10.fc12 works correctly. It would be great to have an update for the F11 tree, too.
cpuspeed-1.5-10.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/cpuspeed-1.5-10.fc11
cpuspeed-1.5-10.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 509754 has been marked as a duplicate of this bug. ***
Any chance of getting a backport for fc10 ? kernel: 2.6.27.30-170.2.82.fc10.i686 cpuspeed: 1.5-2.fc10.i386 Thanks
(In reply to comment #21) > Any chance of getting a backport for fc10 ? Sure, why not. I'll throw it at updates-testing in a bit.
cpuspeed-1.5-12.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/cpuspeed-1.5-12.fc10
cpuspeed-1.5-12.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.