Bug 140144 - cpuspeed daemon crashes when X is started.
Summary: cpuspeed daemon crashes when X is started.
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-utils
Version: 3
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-20 04:55 UTC by Matt Dill
Modified: 2015-01-04 22:12 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-31 04:35:49 UTC
Type: ---
Embargoed:


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

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.


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