Bug 140144

Summary: cpuspeed daemon crashes when X is started.
Product: [Fedora] Fedora Reporter: Matt Dill <mattdill_us>
Component: kernel-utilsAssignee: Dave Jones <davej>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: mattdm, pfrields, venkatesh.pallipadi
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-31 04:35:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace dump of 'cpuspeed -i 2' none

Description Matt Dill 2004-11-20 04:55:46 UTC
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 06:35:52 UTC
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 19:20:40 UTC
Created attachment 107122 [details]
strace dump of 'cpuspeed -i 2'

Comment 3 Matt Dill 2004-11-20 19:24:59 UTC
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 19:30:20 UTC
did you run the strace as root ?


Comment 5 Matt Dill 2004-11-20 19:33:53 UTC
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 23:15:02 UTC
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 20:41:06 UTC
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 18:13:45 UTC
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 21:34:23 UTC
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-31 04:35:49 UTC
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.