Created attachment 565468 [details] dmesg of the f17 system Description of problem: I am getting something like this after each boot and KDE login: ============================================= [ INFO: possible recursive locking detected ] 3.3.0-0.rc4.git1.4.fc17.x86_64 #1 Not tainted --------------------------------------------- pulseaudio/1363 is trying to acquire lock: (&(&substream->self_group.lock)->rlock/1){......}, at: [<ffffffffa01ad093>] snd_pcm_action_group+0xa3/0x240 [snd_pcm] but task is already holding lock: (&(&substream->self_group.lock)->rlock/1){......}, at: [<ffffffffa01ad093>] snd_pcm_action_group+0xa3/0x240 [snd_pcm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&substream->self_group.lock)->rlock/1); lock(&(&substream->self_group.lock)->rlock/1); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by pulseaudio/1363: #0: (snd_pcm_link_rwlock){......}, at: [<ffffffffa01ade62>] snd_pcm_drop+0x62/0x110 [snd_pcm] #1: (&(&substream->self_group.lock)->rlock){......}, at: [<ffffffffa01ade6a>] snd_pcm_drop+0x6a/0x110 [snd_pcm] #2: (&(&substream->group->lock)->rlock){......}, at: [<ffffffffa01ad3ce>] snd_pcm_action+0x3e/0xb0 [snd_pcm] #3: (&(&substream->self_group.lock)->rlock/1){......}, at: [<ffffffffa01ad093>] snd_pcm_action_group+0xa3/0x240 [snd_pcm] stack backtrace: Pid: 1363, comm: pulseaudio Not tainted 3.3.0-0.rc4.git1.4.fc17.x86_64 #1 Call Trace: [<ffffffff810cc20f>] __lock_acquire+0x168f/0x1bb0 [<ffffffff810cae8e>] ? __lock_acquire+0x30e/0x1bb0 [<ffffffff810cce01>] lock_acquire+0xa1/0x1e0 [<ffffffffa01ad093>] ? snd_pcm_action_group+0xa3/0x240 [snd_pcm] [<ffffffff8169dd14>] _raw_spin_lock_nested+0x44/0x80 [<ffffffffa01ad093>] ? snd_pcm_action_group+0xa3/0x240 [snd_pcm] [<ffffffffa01ad093>] snd_pcm_action_group+0xa3/0x240 [snd_pcm] [<ffffffffa01ad401>] snd_pcm_action+0x71/0xb0 [snd_pcm] [<ffffffffa01ad45a>] snd_pcm_stop+0x1a/0x20 [snd_pcm] [<ffffffffa01ade84>] snd_pcm_drop+0x84/0x110 [snd_pcm] [<ffffffffa01afba8>] snd_pcm_common_ioctl1+0x4a8/0xbe0 [snd_pcm] [<ffffffffa01b0650>] snd_pcm_playback_ioctl1+0x60/0x2d0 [snd_pcm] [<ffffffff812c2191>] ? file_has_perm+0xe1/0xf0 [<ffffffffa01b08f4>] snd_pcm_playback_ioctl+0x34/0x40 [snd_pcm] [<ffffffff811d06b9>] do_vfs_ioctl+0x99/0x5a0 [<ffffffff811d0c59>] sys_ioctl+0x99/0xa0 [<ffffffff816a74a9>] system_call_fastpath+0x16/0x1b is this a known problem? the system still works after it. Version-Release number of selected component (if applicable): kernel 3.3.0-0.rc4.git1.4.fc17.x86_64 pulseaudio.x86_64 1.1-3.fc17 @koji-override-0/$releasever pulseaudio-libs.x86_64 1.1-3.fc17 @koji-override-0/$releasever pulseaudio-libs-glib2.x86_64 1.1-3.fc17 @koji-override-0/$releasever pulseaudio-module-bluetooth.x86_64 1.1-3.fc17 @koji-override-0/$releasever pulseaudio-module-x11.x86_64 1.1-3.fc17 @koji-override-0/$releasever pulseaudio-utils.x86_64 1.1-3.fc17 @koji-override-0/$releasever How reproducible: every boot after logging in kde Steps to Reproduce: 1. boot 2. login kde 3. messages in the kernel Actual results: system still operates Additional info:
I believe this is a duplicate of 787319 *** This bug has been marked as a duplicate of bug 787319 ***