Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 cmdline: BOOT_IMAGE=/vmlinuz-3.6.0-0.rc7.git1.4.fc18.x86_64 root=UUID=dece561a-f17d-4ad9-af45-40552960b7da ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 rhgb quiet LANG=en_US.UTF-8 KEYTABLE=us kernel: 3.6.0-0.rc7.git1.4.fc18.x86_64 backtrace: :[ INFO: possible recursive locking detected ] :3.6.0-0.rc7.git1.4.fc18.x86_64 #1 Not tainted :--------------------------------------------- :obex-data-serve/1471 is trying to acquire lock: : (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa02fa889>] bt_accept_dequeue+0xa9/0x190 [bluetooth] :but task is already holding lock: : (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa04c857d>] rfcomm_sock_accept+0x5d/0x2d0 [rfcomm] :other info that might help us debug this: : Possible unsafe locking scenario: : CPU0 : ---- : lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); : lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); : *** DEADLOCK *** : May be due to missing lock nesting notation :1 lock held by obex-data-serve/1471: : #0: (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa04c857d>] rfcomm_sock_accept+0x5d/0x2d0 [rfcomm] :stack backtrace: :Pid: 1471, comm: obex-data-serve Not tainted 3.6.0-0.rc7.git1.4.fc18.x86_64 #1 :Call Trace: : [<ffffffff810d593f>] __lock_acquire+0x15bf/0x1ae0 : [<ffffffff810d138b>] ? add_lock_to_list.isra.29.constprop.44+0x7b/0xd0 : [<ffffffff81021dc3>] ? native_sched_clock+0x13/0x80 : [<ffffffff81021e39>] ? sched_clock+0x9/0x10 : [<ffffffff810ac8c5>] ? sched_clock_cpu+0xc5/0x120 : [<ffffffff810d6541>] lock_acquire+0xa1/0x1f0 : [<ffffffffa02fa889>] ? bt_accept_dequeue+0xa9/0x190 [bluetooth] : [<ffffffff81581acd>] lock_sock_nested+0x8d/0xa0 : [<ffffffffa02fa889>] ? bt_accept_dequeue+0xa9/0x190 [bluetooth] : [<ffffffff810d70cd>] ? trace_hardirqs_on_caller+0x10d/0x1a0 : [<ffffffffa02fa889>] bt_accept_dequeue+0xa9/0x190 [bluetooth] : [<ffffffffa04c8666>] rfcomm_sock_accept+0x146/0x2d0 [rfcomm] : [<ffffffff810a98a0>] ? try_to_wake_up+0x350/0x350 : [<ffffffff8157f602>] sys_accept4+0xf2/0x200 : [<ffffffff816e7395>] ? sysret_check+0x22/0x5d : [<ffffffff810d70cd>] ? trace_hardirqs_on_caller+0x10d/0x1a0 : [<ffffffff8110232c>] ? __audit_syscall_entry+0xcc/0x300 : [<ffffffff8157f720>] sys_accept+0x10/0x20 : [<ffffffff816e7369>] system_call_fastpath+0x16/0x1b
Are you still able to recreate this with kernel-debug-3.6.6 or newer?
Closing insufficient data as needinfo has been set for some time with no response.