Bug 198204
| Summary: | Circ Lock Dep reported in kernel | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | pfrields, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-07-11 05:18:48 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: | |||
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