Date: Thu, 9 Jun 2005 23:56:07 +0200 From: Fredrik Lindberg <fli+freebsd-current@shapeshifter.se> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: _mtx_lock_sleep: recursed on non-recursive mutex pcm0 Message-ID: <20050609215606.GA1813@shapeshifter.se> In-Reply-To: <200506082139.j58Ld4be025180@gw.catspoiler.org> References: <20050608142039.GA776@shapeshifter.se> <200506082139.j58Ld4be025180@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 08, 2005 at 02:39:04PM -0700, Don Lewis (truckman@FreeBSD.org) wrote: > 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 @ /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. > > [cut backtrace] > > 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. Yes, manually creating vchans works without problems. So the issue is most likley, as you said, somewhere during channel creation. > > 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. I ran this with WITNESS enabled too, and yes it complains a few times about malloc. malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc1be9bc0) locked @ /usr/src/sys/dev/sound/pcm/dsp.c:214 I'm not posting the full backtrace, since quite large, but the importat bits are similar to the backtrace produced from the crash dump. malloc(8,c081c400,102,100,c07ca0ea) at malloc+0xd9 vchan_create(c1bf0180,0,c07ca0ea,bf,3) at vchan_create+0x4e pcm_chnalloc(c1979800,1,2e7,ffffffff,0) at pcm_chnalloc+0x114 dsp_open(c1a8ec00,2,2000,c2072c80,c1a8ec00) at dsp_open+0x2dd I'll try to dig around some more and see if I can come up with something. Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050609215606.GA1813>