Bug 556462 - kernel-2.6.33-0.14.rc4.git3.fc13.x86_64: possible recursive locking detected
Summary: kernel-2.6.33-0.14.rc4.git3.fc13.x86_64: possible recursive locking detected
Keywords:
Status: CLOSED DUPLICATE of bug 571969
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Anton Arapov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-18 14:15 UTC by Tom London
Modified: 2014-06-18 08:02 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-03-11 09:18:38 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Tom London 2010-01-18 14:15:39 UTC 
Description of problem:
I got this during shutdown.

System is Thinkpad X200/Rawhide (+ some koji packages).

Jan 17 21:46:33 tlondon init: Disconnected from system bus
Jan 17 21:46:34 tlondon rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w"
Jan 17 21:46:34 tlondon auditd[1141]: The audit daemon is exiting.
Jan 17 21:46:34 tlondon kernel: type=1305 audit(1263793594.410:95): audit_pid=0 old=1141 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jan 17 21:46:35 tlondon cpuspeed: Disabling ondemand cpu frequency scaling governor
Jan 17 21:46:35 tlondon kernel:
Jan 17 21:46:35 tlondon kernel: =============================================
Jan 17 21:46:35 tlondon kernel: [ INFO: possible recursive locking detected ]
Jan 17 21:46:35 tlondon kernel: 2.6.33-0.14.rc4.git3.fc13.x86_64 #1
Jan 17 21:46:35 tlondon kernel: ---------------------------------------------
Jan 17 21:46:35 tlondon kernel: K99cpuspeed/14982 is trying to acquire lock:
Jan 17 21:46:35 tlondon kernel: (s_active){++++.+}, at: [<ffffffff811761c2>] sysfs_addrm_finish+0x36/0x55
Jan 17 21:46:35 tlondon kernel:
Jan 17 21:46:35 tlondon kernel: but task is already holding lock:
Jan 17 21:46:35 tlondon kernel: (s_active){++++.+}, at: [<ffffffff8117637d>] sysfs_get_active_two+0x24/0x48
Jan 17 21:46:35 tlondon kernel:
Jan 17 21:46:35 tlondon kernel: other info that might help us debug this:
Jan 17 21:46:35 tlondon kernel: 4 locks held by K99cpuspeed/14982:
Jan 17 21:46:35 tlondon kernel: #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81174e63>] sysfs_write_file+0x3c/0x144
Jan 17 21:46:35 tlondon kernel: #1:  (s_active){++++.+}, at: [<ffffffff8117637d>] sysfs_get_active_two+0x24/0x48
Jan 17 21:46:35 tlondon kernel: #2:  (s_active){++++.+}, at: [<ffffffff8117638a>] sysfs_get_active_two+0x31/0x48
Jan 17 21:46:35 tlondon kernel: #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa0372d99>] cpufreq_governor_dbs+0x2a1/0x350 [cpufreq_ondemand]
Jan 17 21:46:35 tlondon kernel:
Jan 17 21:46:35 tlondon kernel: stack backtrace:
Jan 17 21:46:35 tlondon kernel: Pid: 14982, comm: K99cpuspeed Not tainted 2.6.33-0.14.rc4.git3.fc13.x86_64 #1
Jan 17 21:46:35 tlondon kernel: Call Trace:
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107e4b3>] __lock_acquire+0xca2/0xd19
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107cd0a>] ? mark_held_locks+0x52/0x70
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107d0eb>] ? debug_check_no_locks_freed+0x12e/0x145
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107cf8a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107e606>] lock_acquire+0xdc/0x102
Jan 17 21:46:35 tlondon kernel: [<ffffffff811761c2>] ? sysfs_addrm_finish+0x36/0x55
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107c0de>] ? lockdep_init_map+0x9e/0x113
Jan 17 21:46:35 tlondon kernel: [<ffffffff81175bcf>] sysfs_deactivate+0x9a/0x103
Jan 17 21:46:35 tlondon kernel: [<ffffffff811761c2>] ? sysfs_addrm_finish+0x36/0x55
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107b852>] ? trace_hardirqs_off+0xd/0xf
Jan 17 21:46:35 tlondon kernel: [<ffffffff81475795>] ? __mutex_unlock_slowpath+0x120/0x132
Jan 17 21:46:35 tlondon kernel: [<ffffffff811761c2>] sysfs_addrm_finish+0x36/0x55
Jan 17 21:46:35 tlondon kernel: [<ffffffff81174530>] sysfs_hash_and_remove+0x53/0x6a
Jan 17 21:46:35 tlondon kernel: [<ffffffff811775d0>] sysfs_remove_group+0x71/0xa9
Jan 17 21:46:35 tlondon kernel: [<ffffffffa0372dac>] cpufreq_governor_dbs+0x2b4/0x350 [cpufreq_ondemand]
Jan 17 21:46:35 tlondon kernel: [<ffffffff813a186b>] __cpufreq_governor+0x9b/0xde
Jan 17 21:46:35 tlondon kernel: [<ffffffff813a26b7>] __cpufreq_set_policy+0x1ce/0x275
Jan 17 21:46:35 tlondon kernel: [<ffffffff813a2bdb>] store_scaling_governor+0x1a7/0x1fb
Jan 17 21:46:35 tlondon kernel: [<ffffffff813a2ee4>] ? handle_update+0x0/0x39
Jan 17 21:46:35 tlondon kernel: [<ffffffff814760b0>] ? down_write+0x7a/0x81
Jan 17 21:46:35 tlondon kernel: [<ffffffff813a24c4>] store+0x61/0x86
Jan 17 21:46:35 tlondon kernel: [<ffffffff81174f2f>] sysfs_write_file+0x108/0x144
Jan 17 21:46:35 tlondon kernel: [<ffffffff8111e289>] vfs_write+0xae/0x10b
Jan 17 21:46:35 tlondon kernel: [<ffffffff8107cf8a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 17 21:46:35 tlondon kernel: [<ffffffff8111e3a6>] sys_write+0x4a/0x6e
Jan 17 21:46:35 tlondon kernel: [<ffffffff81009c32>] system_call_fastpath+0x16/0x1b
Jan 17 21:46:35 tlondon init: rc main process (14621) stopped by STOP signal
Jan 17 21:46:35 tlondon dnsmasq[1718]: exiting on receipt of SIGTERM
Jan 17 21:46:35 tlondon init: rc main process (14621) continued by CONT signal
Jan 17 21:46:35 tlondon kernel: Kernel logging (proc) stopped.


Version-Release number of selected component (if applicable):
kernel-2.6.33-0.14.rc4.git3.fc13.x86_64

How reproducible:
Got this on first boot of kernel-2.6.33-0.14.rc4.git3.fc13.x86_64

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tom London 2010-01-18 17:45:52 UTC 
Happened on very next shutdown as well....:

Jan 18 08:20:04 tlondon auditd[1171]: The audit daemon is exiting.
Jan 18 08:20:04 tlondon kernel: type=1305 audit(1263831604.085:41): audit_pid=0 old=1171 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jan 18 08:20:05 tlondon cpuspeed: Disabling ondemand cpu frequency scaling governor
Jan 18 08:20:05 tlondon kernel:
Jan 18 08:20:05 tlondon kernel: =============================================
Jan 18 08:20:05 tlondon kernel: [ INFO: possible recursive locking detected ]
Jan 18 08:20:05 tlondon kernel: 2.6.33-0.14.rc4.git3.fc13.x86_64 #1
Jan 18 08:20:05 tlondon kernel: ---------------------------------------------
Jan 18 08:20:05 tlondon kernel: K99cpuspeed/9663 is trying to acquire lock:
Jan 18 08:20:05 tlondon kernel: (s_active){++++.+}, at: [<ffffffff811761c2>] sysfs_addrm_finish+0x36/0x55
Jan 18 08:20:05 tlondon kernel:
Jan 18 08:20:05 tlondon kernel: but task is already holding lock:
Jan 18 08:20:05 tlondon kernel: (s_active){++++.+}, at: [<ffffffff8117637d>] sysfs_get_active_two+0x24/0x48
Jan 18 08:20:05 tlondon kernel:
Jan 18 08:20:05 tlondon kernel: other info that might help us debug this:
Jan 18 08:20:05 tlondon kernel: 4 locks held by K99cpuspeed/9663:
Jan 18 08:20:05 tlondon kernel: #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81174e63>] sysfs_write_file+0x3c/0x144
Jan 18 08:20:05 tlondon kernel: #1:  (s_active){++++.+}, at: [<ffffffff8117637d>] sysfs_get_active_two+0x24/0x48
Jan 18 08:20:05 tlondon kernel: #2:  (s_active){++++.+}, at: [<ffffffff8117638a>] sysfs_get_active_two+0x31/0x48
Jan 18 08:20:05 tlondon kernel: #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa0387d99>] cpufreq_governor_dbs+0x2a1/0x350 [cpufreq_ondemand]
Jan 18 08:20:05 tlondon kernel:
Jan 18 08:20:05 tlondon kernel: stack backtrace:
Jan 18 08:20:05 tlondon kernel: Pid: 9663, comm: K99cpuspeed Not tainted 2.6.33-0.14.rc4.git3.fc13.x86_64 #1
Jan 18 08:20:05 tlondon kernel: Call Trace:
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107e4b3>] __lock_acquire+0xca2/0xd19
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107cd0a>] ? mark_held_locks+0x52/0x70
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107d0eb>] ? debug_check_no_locks_freed+0x12e/0x145
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107cf8a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107e606>] lock_acquire+0xdc/0x102
Jan 18 08:20:05 tlondon kernel: [<ffffffff811761c2>] ? sysfs_addrm_finish+0x36/0x55
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107c0de>] ? lockdep_init_map+0x9e/0x113
Jan 18 08:20:05 tlondon kernel: [<ffffffff81175bcf>] sysfs_deactivate+0x9a/0x103
Jan 18 08:20:05 tlondon kernel: [<ffffffff811761c2>] ? sysfs_addrm_finish+0x36/0x55
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107b852>] ? trace_hardirqs_off+0xd/0xf
Jan 18 08:20:05 tlondon kernel: [<ffffffff81475795>] ? __mutex_unlock_slowpath+0x120/0x132
Jan 18 08:20:05 tlondon kernel: [<ffffffff811761c2>] sysfs_addrm_finish+0x36/0x55
Jan 18 08:20:05 tlondon kernel: [<ffffffff81174530>] sysfs_hash_and_remove+0x53/0x6a
Jan 18 08:20:05 tlondon kernel: [<ffffffff811775d0>] sysfs_remove_group+0x71/0xa9
Jan 18 08:20:05 tlondon kernel: [<ffffffffa0387dac>] cpufreq_governor_dbs+0x2b4/0x350 [cpufreq_ondemand]
Jan 18 08:20:05 tlondon kernel: [<ffffffff813a186b>] __cpufreq_governor+0x9b/0xde
Jan 18 08:20:05 tlondon kernel: [<ffffffff813a26b7>] __cpufreq_set_policy+0x1ce/0x275
Jan 18 08:20:05 tlondon kernel: [<ffffffff813a2bdb>] store_scaling_governor+0x1a7/0x1fb
Jan 18 08:20:05 tlondon kernel: [<ffffffff813a2ee4>] ? handle_update+0x0/0x39
Jan 18 08:20:05 tlondon kernel: [<ffffffff814760b0>] ? down_write+0x7a/0x81
Jan 18 08:20:05 tlondon kernel: [<ffffffff813a24c4>] store+0x61/0x86
Jan 18 08:20:05 tlondon kernel: [<ffffffff81174f2f>] sysfs_write_file+0x108/0x144
Jan 18 08:20:05 tlondon kernel: [<ffffffff8111e289>] vfs_write+0xae/0x10b
Jan 18 08:20:05 tlondon kernel: [<ffffffff8107cf8a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 18 08:20:05 tlondon kernel: [<ffffffff8111e3a6>] sys_write+0x4a/0x6e
Jan 18 08:20:05 tlondon kernel: [<ffffffff81009c32>] system_call_fastpath+0x16/0x1b
Jan 18 08:20:05 tlondon init: rc main process (9304) stopped by STOP signal
Jan 18 08:20:05 tlondon init: rc main process (9304) continued by CONT signal
Jan 18 08:20:05 tlondon dnsmasq[1673]: exiting on receipt of SIGTERM
Jan 18 08:20:05 tlondon bluetoothd[1465]: bridge pan0 removed
Jan 18 08:20:05 tlondon bluetoothd[1465]: Stopping SDP server
Jan 18 08:20:05 tlondon bluetoothd[1465]: Exit
Jan 18 08:20:05 tlondon kernel: Kernel logging (proc) stopped.
Comment 2 Tom London 2010-01-19 14:38:07 UTC 
Happens with kernel-2.6.33-0.16.rc4.git6.fc13.x86_64 too:

Jan 18 16:41:14 tlondon rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w"
Jan 18 16:41:14 tlondon auditd[1143]: The audit daemon is exiting.
Jan 18 16:41:14 tlondon kernel: type=1305 audit(1263861674.316:31): audit_pid=0 old=1143 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jan 18 16:41:15 tlondon cpuspeed: Disabling ondemand cpu frequency scaling governor
Jan 18 16:41:15 tlondon kernel:
Jan 18 16:41:15 tlondon kernel: =============================================
Jan 18 16:41:15 tlondon kernel: [ INFO: possible recursive locking detected ]
Jan 18 16:41:15 tlondon kernel: 2.6.33-0.16.rc4.git6.fc13.x86_64 #1
Jan 18 16:41:15 tlondon kernel: ---------------------------------------------
Jan 18 16:41:15 tlondon kernel: K99cpuspeed/3257 is trying to acquire lock:
Jan 18 16:41:15 tlondon kernel: (s_active){++++.+}, at: [<ffffffff81175fde>] sysfs_addrm_finish+0x36/0x55
Jan 18 16:41:15 tlondon kernel:
Jan 18 16:41:15 tlondon kernel: but task is already holding lock:
Jan 18 16:41:15 tlondon kernel: (s_active){++++.+}, at: [<ffffffff81176199>] sysfs_get_active_two+0x24/0x48
Jan 18 16:41:15 tlondon kernel:
Jan 18 16:41:15 tlondon kernel: other info that might help us debug this:
Jan 18 16:41:15 tlondon kernel: 4 locks held by K99cpuspeed/3257:
Jan 18 16:41:15 tlondon kernel: #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81174c7f>] sysfs_write_file+0x3c/0x144
Jan 18 16:41:15 tlondon kernel: #1:  (s_active){++++.+}, at: [<ffffffff81176199>] sysfs_get_active_two+0x24/0x48
Jan 18 16:41:15 tlondon kernel: #2:  (s_active){++++.+}, at: [<ffffffff811761a6>] sysfs_get_active_two+0x31/0x48
Jan 18 16:41:15 tlondon kernel: #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa0390d99>] cpufreq_governor_dbs+0x2a1/0x350 [cpufreq_ondemand]
Jan 18 16:41:15 tlondon kernel:
Jan 18 16:41:15 tlondon kernel: stack backtrace:
Jan 18 16:41:15 tlondon kernel: Pid: 3257, comm: K99cpuspeed Not tainted 2.6.33-0.16.rc4.git6.fc13.x86_64 #1
Jan 18 16:41:15 tlondon kernel: Call Trace:
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107e533>] __lock_acquire+0xca2/0xd19
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107cd8a>] ? mark_held_locks+0x52/0x70
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107d16b>] ? debug_check_no_locks_freed+0x12e/0x145
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107d00a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107e686>] lock_acquire+0xdc/0x102
Jan 18 16:41:15 tlondon kernel: [<ffffffff81175fde>] ? sysfs_addrm_finish+0x36/0x55
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107c15e>] ? lockdep_init_map+0x9e/0x113
Jan 18 16:41:15 tlondon kernel: [<ffffffff811759eb>] sysfs_deactivate+0x9a/0x103
Jan 18 16:41:15 tlondon kernel: [<ffffffff81175fde>] ? sysfs_addrm_finish+0x36/0x55
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107b8d2>] ? trace_hardirqs_off+0xd/0xf
Jan 18 16:41:15 tlondon kernel: [<ffffffff8147560d>] ? __mutex_unlock_slowpath+0x120/0x132
Jan 18 16:41:15 tlondon kernel: [<ffffffff81175fde>] sysfs_addrm_finish+0x36/0x55
Jan 18 16:41:15 tlondon kernel: [<ffffffff8117434c>] sysfs_hash_and_remove+0x53/0x6a
Jan 18 16:41:15 tlondon kernel: [<ffffffff811773ec>] sysfs_remove_group+0x71/0xa9
Jan 18 16:41:15 tlondon kernel: [<ffffffffa0390dac>] cpufreq_governor_dbs+0x2b4/0x350 [cpufreq_ondemand]
Jan 18 16:41:15 tlondon kernel: [<ffffffff813a16cf>] __cpufreq_governor+0x9b/0xde
Jan 18 16:41:15 tlondon kernel: [<ffffffff813a251b>] __cpufreq_set_policy+0x1ce/0x275
Jan 18 16:41:15 tlondon kernel: [<ffffffff813a2a3f>] store_scaling_governor+0x1a7/0x1fb
Jan 18 16:41:15 tlondon kernel: [<ffffffff813a2d48>] ? handle_update+0x0/0x39
Jan 18 16:41:15 tlondon kernel: [<ffffffff81475f28>] ? down_write+0x7a/0x81
Jan 18 16:41:15 tlondon kernel: [<ffffffff813a2328>] store+0x61/0x86
Jan 18 16:41:15 tlondon kernel: [<ffffffff81174d4b>] sysfs_write_file+0x108/0x144
Jan 18 16:41:15 tlondon kernel: [<ffffffff8111e2e5>] vfs_write+0xae/0x10b
Jan 18 16:41:15 tlondon kernel: [<ffffffff8107d00a>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 18 16:41:15 tlondon kernel: [<ffffffff8111e402>] sys_write+0x4a/0x6e
Jan 18 16:41:15 tlondon kernel: [<ffffffff81009c32>] system_call_fastpath+0x16/0x1b
Jan 18 16:41:15 tlondon init: rc main process (2956) stopped by STOP signal
Jan 18 16:41:15 tlondon kernel: Kernel logging (proc) stopped.
Comment 3 Tom London 2010-01-27 18:53:28 UTC 
FYI, this continues with kernel-2.6.33-0.23.rc5.git1.fc13.x86_64:

Jan 27 09:50:01 tlondon rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w"
Jan 27 09:50:01 tlondon auditd[1119]: The audit daemon is exiting.
Jan 27 09:50:01 tlondon kernel: type=1305 audit(1264614601.974:15): audit_pid=0 old=1119 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Jan 27 09:50:02 tlondon cpuspeed: Disabling ondemand cpu frequency scaling governor
Jan 27 09:50:02 tlondon kernel:
Jan 27 09:50:02 tlondon kernel: =============================================
Jan 27 09:50:02 tlondon kernel: [ INFO: possible recursive locking detected ]
Jan 27 09:50:02 tlondon kernel: 2.6.33-0.23.rc5.git1.fc13.x86_64 #1
Jan 27 09:50:02 tlondon kernel: ---------------------------------------------
Jan 27 09:50:02 tlondon kernel: K99cpuspeed/2076 is trying to acquire lock:
Jan 27 09:50:02 tlondon kernel: (s_active){++++.+}, at: [<ffffffff81176006>] sysfs_addrm_finish+0x36/0x55
Jan 27 09:50:02 tlondon kernel:
Jan 27 09:50:02 tlondon kernel: but task is already holding lock:
Jan 27 09:50:02 tlondon kernel: (s_active){++++.+}, at: [<ffffffff811761c1>] sysfs_get_active_two+0x24/0x48
Jan 27 09:50:02 tlondon kernel:
Jan 27 09:50:02 tlondon kernel: other info that might help us debug this:
Jan 27 09:50:02 tlondon kernel: 4 locks held by K99cpuspeed/2076:
Jan 27 09:50:02 tlondon kernel: #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81174ca7>] sysfs_write_file+0x3c/0x144
Jan 27 09:50:02 tlondon kernel: #1:  (s_active){++++.+}, at: [<ffffffff811761c1>] sysfs_get_active_two+0x24/0x48
Jan 27 09:50:02 tlondon kernel: #2:  (s_active){++++.+}, at: [<ffffffff811761ce>] sysfs_get_active_two+0x31/0x48
Jan 27 09:50:02 tlondon kernel: #3:  (dbs_mutex){+.+.+.}, at: [<ffffffffa0389d99>] cpufreq_governor_dbs+0x2a1/0x350 [cpufreq_ondemand]
Jan 27 09:50:02 tlondon kernel:
Jan 27 09:50:02 tlondon kernel: stack backtrace:
Jan 27 09:50:02 tlondon kernel: Pid: 2076, comm: K99cpuspeed Not tainted 2.6.33-0.23.rc5.git1.fc13.x86_64 #1
Jan 27 09:50:02 tlondon kernel: Call Trace:
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107e547>] __lock_acquire+0xca2/0xd19
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107cd9e>] ? mark_held_locks+0x52/0x70
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107d17f>] ? debug_check_no_locks_freed+0x12e/0x145
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107d01e>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107e69a>] lock_acquire+0xdc/0x102
Jan 27 09:50:02 tlondon kernel: [<ffffffff81176006>] ? sysfs_addrm_finish+0x36/0x55
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107c172>] ? lockdep_init_map+0x9e/0x113
Jan 27 09:50:02 tlondon kernel: [<ffffffff81175a13>] sysfs_deactivate+0x9a/0x103
Jan 27 09:50:02 tlondon kernel: [<ffffffff81176006>] ? sysfs_addrm_finish+0x36/0x55
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107b8e6>] ? trace_hardirqs_off+0xd/0xf
Jan 27 09:50:02 tlondon kernel: [<ffffffff8147595e>] ? __mutex_unlock_slowpath+0x120/0x132
Jan 27 09:50:02 tlondon kernel: [<ffffffff81176006>] sysfs_addrm_finish+0x36/0x55
Jan 27 09:50:02 tlondon kernel: [<ffffffff81174374>] sysfs_hash_and_remove+0x53/0x6a
Jan 27 09:50:02 tlondon kernel: [<ffffffff81177414>] sysfs_remove_group+0x71/0xa9
Jan 27 09:50:02 tlondon kernel: [<ffffffffa0389dac>] cpufreq_governor_dbs+0x2b4/0x350 [cpufreq_ondemand]
Jan 27 09:50:02 tlondon kernel: [<ffffffff813a1a1b>] __cpufreq_governor+0x9b/0xde
Jan 27 09:50:02 tlondon kernel: [<ffffffff813a2867>] __cpufreq_set_policy+0x1ce/0x275
Jan 27 09:50:02 tlondon kernel: [<ffffffff813a2d8b>] store_scaling_governor+0x1a7/0x1fb
Jan 27 09:50:02 tlondon kernel: [<ffffffff813a3094>] ? handle_update+0x0/0x39
Jan 27 09:50:02 tlondon kernel: [<ffffffff81476279>] ? down_write+0x7a/0x81
Jan 27 09:50:02 tlondon kernel: [<ffffffff813a2674>] store+0x61/0x86
Jan 27 09:50:02 tlondon kernel: [<ffffffff81174d73>] sysfs_write_file+0x108/0x144
Jan 27 09:50:02 tlondon kernel: [<ffffffff8111e311>] vfs_write+0xae/0x10b
Jan 27 09:50:02 tlondon kernel: [<ffffffff8107d01e>] ? trace_hardirqs_on_caller+0x111/0x135
Jan 27 09:50:02 tlondon kernel: [<ffffffff8111e42e>] sys_write+0x4a/0x6e
Jan 27 09:50:02 tlondon kernel: [<ffffffff81009c32>] system_call_fastpath+0x16/0x1b
Jan 27 09:50:02 tlondon kernel: Kernel logging (proc) stopped.
Comment 4 Tom London 2010-02-02 16:59:15 UTC 
FYI, continues with kernel-2.6.33-0.26.rc6.git1.fc13.x86_64
Comment 5 Mike Fedyk 2010-02-20 00:13:14 UTC 
I get this as well on 2.6.33-0.46.rc8.git1.fc13.x86_64
Comment 6 Mattia Verga 2010-02-28 09:13:29 UTC 
I get it also with 2.6.33-1.fc13.x86_64
Comment 7 Gene Snider 2010-02-28 22:56:50 UTC 
I got it with 2.6.33, and still getting it with 2.6.34-0.4.rc0.git2.fc14.x86_64
Comment 8 Tom London 2010-03-11 00:56:02 UTC 
Not 100% sure, but I believe I am no longer seeing this with kernel-2.6.34-0.10.rc1.git0.fc14.x86_64
Comment 9 Anton Arapov 2010-03-11 09:18:38 UTC 
look at bug 571969 for the details.

*** This bug has been marked as a duplicate of bug 571969 ***
Note You need to log in before you can comment on or make changes to this bug.