Bug 132384 - cpuspeed -i parameter (and default of 20) is incorrectly implemented (as whole seconds rather than tenths)
cpuspeed -i parameter (and default of 20) is incorrectly implemented (as whol...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cpuspeed (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jarod Wilson
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-11 22:09 EDT by David Baron
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-08 12:02:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Here is a patch to fix the -i parameter. (528 bytes, patch)
2005-01-02 07:36 EST, Peter Osterlund
no flags Details | Diff

  None (edit)
Description David Baron 2004-09-11 22:09:51 EDT
Description of problem:  The cpuspeed parameter "-i" is incorrectly
documented.  The error messages printed when running either:
 /usr/sbin/cpuspeed -i
or
 /usr/sbin/cpuspeed -h
both say that the argument to -i is a time in tenths of a second. 
Both examination of the code and testing show that it is in whole
seconds.  (And the default is 20 seconds, not 20 tenths of a second,
as documented.)

Version-Release number of selected component (if applicable):
  kernel-utils-2.4-9.1.131
Comment 1 David Baron 2004-09-11 22:17:45 EDT
Note that this is a bug in cpuspeed.patch, not in the original source.
 And perhaps it should be corrected by fixing the patch rather than
the documentation, for compatibility with the original cpuspeed.
Comment 2 Michal Szymanski 2004-09-28 06:58:03 EDT
I fully agree to the latter comment. The change from 1/10 to full
second in the interval specification is obviously a bug, especially if
the default interval (20) was kept unchanged. As it is shipped now,
cpuspeed is not doing the right job: waiting 20 (or more) seconds to
get CPU running at full speed is a nonsense! Most jobs (short
compiles, test runs, displaying images and so on) complete well before
any change in CPU freq occurs. And so the user has typically no gain
from his/her fast processor.
regards, Michal.
Comment 3 Peter Osterlund 2005-01-02 07:36:04 EST
Created attachment 109233 [details]
Here is a patch to fix the -i parameter.

Here is a patch to fix the -i parameter.
Comment 4 Matthew Miller 2005-04-26 12:14:35 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 5 David Baron 2005-04-26 12:21:48 EDT
Changing version from fc2 to fc3.

The attitude of assuming that bugs have been fixed even if nobody has looked at
them seems like a bad one.  It just highlights the fact that many bugs aren't
looked at and discourages users from filing bugs.
Comment 6 Matthew Miller 2005-04-26 13:43:29 EDT
I'm sorry, but Fedora Legacy doesn't have the resources to go through and
evaluate all non-security FC2 bugs; that's why we're asking for your help. 

We're *not* assuming that all such bugs are fixed, but rather showing the
reality that unless there's some activity, these bugs *won't* get fixed.


I understand what you're saying about how this may discourage users from filing
bugs, but I think it's better to reflect reality than to let these completely
languish and just have nothing ever happen to them -- that's pretty discouraging
too.

I often wish Red Hat developers would have an infinite amount of time,
resources, and energy to look at my issues too, but again, there's reality.
Fedora Core *is* a community project, and so often active participation is
required to get these things addressed. Hopefully, reducing cruft in Bugzilla
will make it more useful to the core developers and lead to *better* overall
response.
Comment 7 Matthew Miller 2006-07-10 17:30:00 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 8 David Baron 2006-07-10 17:57:18 EDT
By source code inspection of a cvs checkout from fedora cvs, this is still an
issue in cpuspeed.patch in both FC-5 and devel.

(In reply to comment #6)
> I often wish Red Hat developers would have an infinite amount of time,
> resources, and energy to look at my issues too, but again, there's reality.
> Fedora Core *is* a community project, and so often active participation is
> required to get these things addressed.

If this is a community project, do you accept patches from the community? 
What's the process for getting patches (like the one on this bug) that are being
ignored to be incorporated?
Comment 9 Matthew Miller 2006-07-11 10:56:22 EDT
I agree. It's a serious issue. Part of the point of this review of old open bugs
is to help get attention for the ones that need it.
Comment 10 Jarod Wilson 2007-01-08 12:02:35 EST
This appears to be fixed in cpuspeed 1.2.1, which fc5, fc6 and rawhide all
feature now. Essentially the same thing proposed by the patch in comment #3 is
done within the program's main loop to convert to tenths of seconds.

Note You need to log in before you can comment on or make changes to this bug.