Bug 140144 - cpuspeed daemon crashes when X is started.
cpuspeed daemon crashes when X is started.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
3
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-19 23:55 EST by Matt Dill
Modified: 2015-01-04 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-30 23:35:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace dump of 'cpuspeed -i 2' (72.11 KB, text/plain)
2004-11-20 14:20 EST, Matt Dill
no flags Details

  None (edit)
Description Matt Dill 2004-11-19 23:55:46 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
Comment 1 Dave Jones 2004-11-20 01:35:52 EST
what happens when you strace it, or run it under gdb ?
any relevant messages in /var/log/messages ?
Comment 2 Matt Dill 2004-11-20 14:20:40 EST
Created attachment 107122 [details]
strace dump of 'cpuspeed -i 2'
Comment 3 Matt Dill 2004-11-20 14:24:59 EST
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.
Comment 4 Dave Jones 2004-11-20 14:30:20 EST
did you run the strace as root ?
Comment 5 Matt Dill 2004-11-20 14:33:53 EST
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.
Comment 6 Matt Dill 2004-11-21 18:15:02 EST
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.
Comment 7 Dave Jones 2004-11-28 15:41:06 EST
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.
Comment 8 Venkatesh Pallipadi 2005-03-07 13:13:45 EST
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.
Comment 9 Matthew Miller 2006-07-10 17:34:23 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 10 John Thacker 2006-10-30 23:35:49 EST
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.

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