Bug 199664 - service start cpuspeed produces deadlock diagnostic
service start cpuspeed produces deadlock diagnostic
Status: CLOSED DUPLICATE of bug 197803
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-21 05:05 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-26 00:11:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2006-07-21 05:05:38 EDT
Description of problem:
Starting cpuspeed, more often than not, on my Athlon64 X2 system, produces the
following diagnostic:

Call Trace:
 [<ffffffff8026e2a9>] show_trace+0xaa/0x23d
 [<ffffffff8026e451>] dump_stack+0x15/0x17
 [<ffffffff802a655c>] print_circular_bug_tail+0x6c/0x77
 [<ffffffff802a7b61>] __lock_acquire+0x853/0xa54
 [<ffffffff802a8303>] lock_acquire+0x4b/0x69
 [<ffffffff80265c39>] __mutex_lock_slowpath+0xe5/0x261
 [<ffffffff80265ddf>] mutex_lock+0x2a/0x2e
 [<ffffffff8040e6a7>] store_scaling_governor+0x14f/0x19c
 [<ffffffff80274fb4>] store+0x4c/0x66
 [<ffffffff80309b19>] sysfs_write_file+0xd1/0x103
 [<ffffffff80217148>] vfs_write+0xcf/0x175
 [<ffffffff80217a30>] sys_write+0x47/0x70
 [<ffffffff8025ff4e>] system_call+0x7e/0x83


Version-Release number of selected component (if applicable):
kernel-2.6.17-1.2416.fc6
cpuspeed-1.2.1-1.36.fc6.1

How reproducible:
Not sure it's every time, but it's quite consistent during boot up

Steps to Reproduce:
1.service cpuspeed start

Additional info:
selinux is disabled, in case the policy above has to do with it.

After the failure, service cpuspeed status says:
cpuspeed dead but subsys locked

and indeed:
root      2482  0.0  0.0   3744   280 ?        Ss   04:22   0:00 cpuspeed -d -n
root      2483  0.0  0.0      0     0 ?        Z    04:22   0:00 [cpuspeed]
<defunct>

but frequency scaling still works, possibly because both cpus scale at the same
time?

I wonder if this has to do with the freezes I've experienced on x86_64 SMP
lately...  One of the times it happens most often is at 4 am, when lots of
cron-started processes come up, presumably requiring more cpu activity than an
otherwise mostly-idle box.
Comment 1 Dave Jones 2006-07-26 00:11:53 EDT

*** This bug has been marked as a duplicate of 197803 ***

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