Bug 216816

Created attachment 141866 [details]
a correction to a startup file for cpuspeed

Created attachment 141946 [details]
corrected src.rpm package

Sigh! The second point was addressed but not the first one.
Source rpm file is small so I attach a new one with corrections
in toto. Warning! Release bumped "by hand".

For the last eight days, until 1.2.1-1.45.fc7 showed up, 'cpuspeed'
rawhide package had its configuration file in one location with
/etc/rc.d/init.d/cpuspeed referencing another one.  I am not aware
of anybody complaining.  Likely this shows the current level of
expectations in this particular case. :-)

I still think that "the least surprise principle" calls for
/etc/sysconfig/cpuspeed as a configuration file instead of
/etc/cpuspeed.conf.

Even more fun, (In reply to comment #3)
> For the last eight days, until 1.2.1-1.45.fc7 showed up, 'cpuspeed'
> rawhide package had its configuration file in one location with
> /etc/rc.d/init.d/cpuspeed referencing another one.  I am not aware
> of anybody complaining.

I saw that independent of this bug yesterday when I rolled 1.45...

Its even more amusing though, because there's actually a bug in your version of
the init script. Its looking for the existence of /etc/cpuspeed/cpuspeed instead
of /etc/sysconfig/cpuspeed, then trying to source /etc/sysconfig/cpuspeed... :)

> Likely this shows the current level of
> expectations in this particular case. :-)

Yeah, I'm guessing most people never alter the config file either.
 
> I still think that "the least surprise principle" calls for
> /etc/sysconfig/cpuspeed as a configuration file instead of
> /etc/cpuspeed.conf.

The type of config file is certainly more /etc/sysconfig-ish, but there's also
the argument that having it in /etc/cpuspeed.conf is less surprising, largely
due to the fact that's where we've been putting it for quite a while. I'm
inclined to believe moving it now probably isn't worth the hassle. Unless
there's a compelling reason to do so that outweighs the possible annoyance to
people who upgrade and have to reconfigure their setup, I'm inclined to close
this bug out...

> Its even more amusing though, because there's actually a bug
> in your version of the init script.

Yeah, you are right.  Not in what I am actually running but in
what I repackaged in an attachmenet to comment #2.  Too much
typing. :-)

On a laptop of my wife I am seeing "FATAL" startup messages for
cpuspeed without a correct config file and a default one from FC6
needs to be replaced.  The same goes for my "rawhide" test box.

I've got FC5 and FC6 builds headed to updates-testing this afternoon. Can you
elaborate on what you're still seeing on your wife's laptop and your rawhide
test box?

> Can you elaborate on what you're still seeing ...

On my rawhide box, after my recent rewrite (which was basically
used in cpuspeed-1.2.1-1.45.fc7) I am not seeing anything.
This is expected as there is just no cpu scaling there.  At
least not with any driver I could find.

On a laptop of my wife (now FC6) with cpuspeed-1.2.1-1.40.fc6
and "out-of-the-box", i.e. just after an installation, I am
greeted with:

FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.18-1.2849.fc6/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):
No such device

or similar. Yes, I know how to fix that and that a CPU scaling actually
works there.  After starting this you will see

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
250000 500000 750000 1000000 1250000 1500000 1750000 2000000

which is a bit much and setting a higher minimum is a good idea
or otherwise things are getting sloooow and it is difficult to coax
CPU to bump onto a higher level.

BTW, it likely would be nice to make that operation more explicit
in a config file; especially that 'man cpuspeed' does not exist.
Something like that:

# Do not set CPU below that (in kHz)
# MIN_SPEED=
[ "$MIN_SPEED" ] && OPTS="$OPTS -m $MIN_SPEED"

If setting max speed with -M could/should be there is something
to think about.

On a rawhide box before recent changes starting cpuspeed service,
which was happening by a default, also was bringing a "FATAL" message
similar to the quoted above.  I realize that in this case this
was just a noise.

*** Bug 218194 has been marked as a duplicate of this bug. ***

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

cpuspeed now simply does not work at all on a hardware I have here
(and where it used to work at least to some extent) and the package
itself went through a number of essential changes.  It does not
look like that all of this is relevant any longer.

I don't quite follow... It doesn't work at all any more where it used to? Are
there open bugs I'm not aware of?

> I don't quite follow... It doesn't work at all any more where it used to?

Yes, indeed, this is the case.  It did work with Fedora 6 on Acer
TravelMate 230 laptop, for some value of "work", but it does not work
anymore after an upgrade to F8.  Regardless how GOVERNOR is set
in /etc/sysconfig/cpuspeed a startup file silently exits.

> Are there open bugs I'm not aware of?

No.  Effects of working cpuspeed were nothing to write home about and
it was my understanding that a support for that hardware was just
dropped.  There was a number of other issues which were more important.
Last time I tried setting DRIVER was of no help either regardless which
one.  I may see at some moment if anything changed with the latest
kernels.

Ah, I'm guessing maybe that laptop used p4-clockmod, which I do believe we
stopped building, since its a pile of junk...

> Ah, I'm guessing maybe that laptop used p4-clockmod
You are most likely right. It was a while.
> since its a pile of junk...
I would not quarrel with this technical assesment.

> Are there open bugs I'm not aware of?

Actually the issue is not so clear-cut as the latest comments would
imply.  See bug 201463 and in particular comment #8 there (which
talks about Fedora 8).  I already forgot but this is the same laptop
involved.