Bug 505837

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.