Red Hat Bugzilla – Bug 140144
cpuspeed daemon crashes when X is started.
Last modified: 2015-01-04 17:12:38 EST
Description of problem: The cpuspeed daemon crashes when X is started. Version-Release number of selected component (if applicable): 2.4-13.1.39 How reproducible: always Steps to Reproduce: 1. boot into runlevel 3 2. run 'ps ax | grep cpuspeed' -> reveals 'cpuspeed -d -i 2' 3. run 'startx', repeat step 2, cpuspeed no longer running. Actual results: cpuspeed also fails to run when booting into runlevel 5. I assume it does start, but again fails when X starts. Expected results: cpuspeed should run so that cpu speed scales properly with load. Additional info: platform: HP ze4805us laptop cpu: Athlon XP-M 2800+ Seemed to work OK in fc2
what happens when you strace it, or run it under gdb ? any relevant messages in /var/log/messages ?
Created attachment 107122 [details] strace dump of 'cpuspeed -i 2'
There doesn't seem to be anything interesting in messages. Again, all works well until X starts and then the daemon dies. If I start cpuspeed again after X is running, it works well thereafter. See above attachment. I'm not sure if it's a permissions problem with scaling_speed or not as that file seems to disappear when cpuspeed dies.
did you run the strace as root ?
Yes. I ran 'strace /usr/sbin/cpuspeed -i 2' from a separate virtual terminal as root, then switched back to the original virtual terminal and ran 'startx' as myself.
It seems that it was /usr/bin/klaptop_acpi_helper that was killing cpuspeed. I disabled the klaptop feature and now cpuspeed is running correctly.
interesting. what package provides that ? It seems quite antisocial behaviour, and I'm quite curious how a userspace app is managing to kill a root process.
Can you see what is there in /sys/*/cpufreq/scaling_governor, when the cpuspeed gets killed. Probably, the klaptop_whatever is changing the governor to somethign other than userspace. And as a result, cpuspeed exits. But, when you restart cpuspeed, he resets the governor back to userspace.
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!
Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.