Re: _mtx_lock_sleep: recursed on non-recursive mutex pcm0

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Wed, 8 Jun 2005 14:39:04 -0700 (PDT)
On  8 Jun, Fredrik Lindberg wrote:
> Hi
> 
> When trying to play sound from two different sources at the same time I get an
> instant panic with the following message
>  
> panic: _mtx_lock_sleep: recursed on non-recursive mutex pcm0 _at_ /usr/src/sys/dev/sound/pcm/sound.c:381
> 
> This is with a <Intel ICH3 (82801CA)> (AC97) on a few hours old current and with
> sound and snd_ich compiled staticly into the kernel.
> It only occurs when hw.snd.autovchans is set to a number greater than 1.
> 
> Backtrace
> #0  doadump () at pcpu.h:165
> #1  0xc059674a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397
> #2  0xc0596ab8 in panic (
>     fmt=0xc07d07d0 "_mtx_lock_sleep: recursed on non-recursive mutex %s _at_ %s:%d\n")
>     at /usr/src/sys/kern/kern_shutdown.c:553
> #3  0xc058cc08 in _mtx_lock_sleep (m=0xc1be9bc0, td=0xc20d8190, opts=0, file=0x0, 
>     line=0) at /usr/src/sys/kern/kern_mutex.c:447
> #4  0xc058c8eb in _mtx_lock_flags (m=0x0, opts=0, 
>     file=0xc07c5c1a "/usr/src/sys/dev/sound/pcm/sound.c", line=381)
>     at /usr/src/sys/kern/kern_mutex.c:273
> #5  0xc0506dfc in pcm_chn_create (d=0xc1979a00, parent=0x0, cls=0x0, dir=2, 
>     devinfo=0x0) at /usr/src/sys/dev/sound/pcm/sound.c:381
> #6  0xc0508a52 in vchan_create (parent=0xc1bf0180)
>     at /usr/src/sys/dev/sound/pcm/vchan.c:265
> #7  0xc05067a4 in pcm_chnalloc (d=0xc1979a00, direction=1, pid=628, chnum=-1)
>     at /usr/src/sys/dev/sound/pcm/sound.c:193
> #8  0xc0500a8d in dsp_open (i_dev=0xc1a99c00, flags=2, mode=8192, td=0xc20d8190)
>     at /usr/src/sys/dev/sound/pcm/dsp.c:275
> #9  0xc053e38b in devfs_open (ap=0xeebb8a54)
>     at /usr/src/sys/fs/devfs/devfs_vnops.c:881
> #10 0xc0792fbc in VOP_OPEN_APV (vop=0x0, a=0xeebb8a54) at vnode_if.c:373
> #11 0xc06089c2 in vn_open_cred (ndp=0xeebb8bc4, flagp=0xeebb8cc4, cmode=0, 
>     cred=0xc20a5900, fdidx=6) at vnode_if.h:198
> #12 0xc0608543 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
>     at /usr/src/sys/kern/vfs_vnops.c:91
> #13 0xc0600668 in kern_open (td=0xc20d8190, path=0x0, pathseg=UIO_USERSPACE, 
>     flags=2, mode=0) at /usr/src/sys/kern/vfs_syscalls.c:986
> #14 0xc0600556 in open (td=0x0, uap=0xeebb8d04)
>     at /usr/src/sys/kern/vfs_syscalls.c:952
> 
> The content of frame 5 yields the following
> (kgdb) f 5
> #5  0xc0506dfc in pcm_chn_create (d=0xc1979a00, parent=0x0, cls=0x0, dir=2, 
>     devinfo=0x0) at /usr/src/sys/dev/sound/pcm/sound.c:381
> 381             snd_mtxlock(d->lock);
> 
> d->lock is initialized as a non-recursive mutex in snd_mtxcreate (sound.c:78) 
> called from pcm_register (sound.c:655).
> While the following patch fixes the panic and let me play sound from different
> sources at the same time without any problems, I'm really not sure this is
> the correct solution since the mutex was initialized as a non-recursive mutex but
> recursion happens anyway. Perhaps somebody with more experience in the sound system
> could look at this.

Try manually creating the vchans ahead of time by setting the
hw.snd.pcm0.vchans to the desired value.  There are a number of locking
bugs and possible race conditions in the top half of the sound code,
especially in the channel creation code.  Pre-creating the vchans
exercises a different code path that should not have this particular
bug.

I'm guessing that your kernel does not have the WITNESS option enabled,
otherwise WITNESS should be complaining about calls to malloc() while
holding a mutex.
Received on Wed Jun 08 2005 - 19:39:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC