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
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.
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.
Created attachment 109233 [details] Here is a patch to fix the -i parameter. Here is a patch to fix the -i parameter.
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.
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.
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.
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!
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?
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.
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.