Bug 797013 - f17 pulseaudio INFO: possible recursive locking detected kernel message
Summary: f17 pulseaudio INFO: possible recursive locking detected kernel message
Keywords:
Status: CLOSED DUPLICATE of bug 787319
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-24 03:10 UTC by Reartes Guillermo
Modified: 2012-02-24 13:44 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-02-24 13:44:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg of the f17 system (123.39 KB, application/octet-stream)
2012-02-24 03:10 UTC, Reartes Guillermo
no flags Details

Description Reartes Guillermo 2012-02-24 03:10:41 UTC
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:

Comment 1 Josh Boyer 2012-02-24 13:44:09 UTC
I believe this is a duplicate of 787319

*** This bug has been marked as a duplicate of bug 787319 ***


Note You need to log in before you can comment on or make changes to this bug.