Bug 198204 - Circ Lock Dep reported in kernel
Circ Lock Dep reported in kernel
Status: CLOSED DUPLICATE of bug 197803
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-10 10:10 EDT by Peter Robinson
Modified: 2015-01-04 17:27 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 01:18:48 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 Peter Robinson 2006-07-10 10:10:18 EDT
kernel version : Linux localhost 2.6.17-1.2356.fc6 #1 SMP Thu Jul 6 01:10:48 EDT
2006 i686 i686 i386 GNU/Linux

On an Intel Centrino Duo (Dell D620) the kernel reports the following possible
circular locking dependency detected...

Not sure if this should be reported in the Fedora kernel, the cpuspeed package
or upstream. I figure its coming from the kernel so here's as good as anywhere else.

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
S06cpuspeed/1812 is trying to acquire lock:
 (dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24

but task is already holding lock:
 (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (cpucontrol){--..}:
       [<c043c546>] lock_acquire+0x4b/0x6d
       [<c060d51e>] __mutex_lock_slowpath+0xbf/0x23b
       [<c060d6bb>] mutex_lock+0x21/0x24
       [<c0440009>] __lock_cpu_hotplug+0x36/0x56
       [<c0440042>] lock_cpu_hotplug+0xa/0xc
       [<c04337de>] __create_workqueue+0x52/0x168
       [<f8b3b32e>] cpufreq_governor_dbs+0x9e/0x2cb [cpufreq_ondemand]
       [<c05a724b>] __cpufreq_governor+0x57/0xd8
       [<c05a7409>] __cpufreq_set_policy+0x13d/0x1a9
       [<c05a760c>] store_scaling_governor+0x128/0x151
       [<c05a6c67>] store+0x37/0x48
       [<c04ab4cc>] sysfs_write_file+0xab/0xd1
       [<c047248b>] vfs_write+0xab/0x157
       [<c0472ace>] sys_write+0x3b/0x60
       [<c0403f2f>] syscall_call+0x7/0xb

-> #0 (dbs_mutex){--..}:
       [<c043c546>] lock_acquire+0x4b/0x6d
       [<c060d51e>] __mutex_lock_slowpath+0xbf/0x23b
       [<c060d6bb>] mutex_lock+0x21/0x24
       [<f8b3b503>] cpufreq_governor_dbs+0x273/0x2cb [cpufreq_ondemand]
       [<c05a724b>] __cpufreq_governor+0x57/0xd8
       [<c05a7463>] __cpufreq_set_policy+0x197/0x1a9
       [<c05a760c>] store_scaling_governor+0x128/0x151
       [<c05a6c67>] store+0x37/0x48
       [<c04ab4cc>] sysfs_write_file+0xab/0xd1
       [<c047248b>] vfs_write+0xab/0x157
       [<c0472ace>] sys_write+0x3b/0x60
       [<c0403f2f>] syscall_call+0x7/0xb

other info that might help us debug this:

2 locks held by S06cpuspeed/1812:
 #0:  (&policy->lock){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24
 #1:  (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24

stack backtrace:
 [<c0405167>] show_trace_log_lvl+0x54/0xfd
 [<c040571e>] show_trace+0xd/0x10
 [<c040583d>] dump_stack+0x19/0x1b
 [<c043b63d>] print_circular_bug_tail+0x59/0x64
 [<c043be35>] __lock_acquire+0x7ed/0x98d
 [<c043c546>] lock_acquire+0x4b/0x6d
 [<c060d51e>] __mutex_lock_slowpath+0xbf/0x23b
 [<c060d6bb>] mutex_lock+0x21/0x24
 [<f8b3b503>] cpufreq_governor_dbs+0x273/0x2cb [cpufreq_ondemand]
 [<c05a724b>] __cpufreq_governor+0x57/0xd8
 [<c05a7463>] __cpufreq_set_policy+0x197/0x1a9
 [<c05a760c>] store_scaling_governor+0x128/0x151
 [<c05a6c67>] store+0x37/0x48
 [<c04ab4cc>] sysfs_write_file+0xab/0xd1
 [<c047248b>] vfs_write+0xab/0x157
 [<c0472ace>] sys_write+0x3b/0x60
 [<c0403f2f>] syscall_call+0x7/0xb
Comment 1 Dave Jones 2006-07-11 01:18:48 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.