Date: Tue, 17 Feb 2004 08:41:00 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: haro@kgt.co.jp Cc: mat@cnd.mcgill.ca Subject: Re: LOR with sound Message-ID: <200402171641.i1HGf07E050235@gw.catspoiler.org> In-Reply-To: <200402161022.i1GAM07E045806@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Feb, To: haro@kgt.co.jp wrote: > On 16 Feb, Munehiro Matsuda wrote: >> Hi all, >> >> I've gotten following LoR with sounde code, using kernel from Feb 15th >> with patch from Mathew Kanner: >> http://docs.freebsd.org/cgi/mid.cgi?20031215185606.GA63202 >> >>> lock order reversal >>> 1st 0xc31ca140 pcm0:play:0 (pcm play channel) @ dev/sound/pcm/channel.c:1069 >>> 2nd 0xc31b6ec0 pcm0:record:0 (pcm record channel) @ dev/sound/pcm/channel.c:1350 >>> Stack backtrace: >>> backtrace(0,ffffffff,c0761120,c0761148,c07303fc) at backtrace+0x12 >>> witness_checkorder(c31b6ec0,9,c06cfeaf,546) at witness_checkorder+0x593 >>> _mtx_lock_flags(c31b6ec0,0,c06cfea6,546,d29f2a70) at _mtx_lock_flags+0x67 >>> chn_lock(c32add80,c,c407b000,c405b000,102) at chn_lock+0x1a >>> sndbuf_remalloc(c31bab00,200,100,c32add80,100) at sndbuf_remalloc+0x8c >>> chn_setblocksize(c32add80,200,0,20000,c31cf718) at chn_setblocksize+0x306 >>> chn_tryspeed(c32add80,1f40) at chn_tryspeed+0x149 >>> chn_tryformat(c32add80,10,10,d29f2c60,d29f2c60) at chn_tryformat+0xaf >>> chn_setformat(c32add80,10,0,c1616a00,c32add80) at chn_setformat+0x15 >>> dsp_ioctl(c075a6a0,c0045005,d29f2c60,3,c3733540) at dsp_ioctl+0x9f2 >>> spec_ioctl(d29f2b88,d29f2c34,c0583df7,d29f2b88,c074fc40) at spec_ioctl+0x12d >>> spec_vnoperate(d29f2b88) at spec_vnoperate+0x13 >>> vn_ioctl(c3778f24,c0045005,d29f2c60,c371f180,c3733540) at vn_ioctl+0x17f >>> ioctl(c3733540,d29f2d14,3,5,296) at ioctl+0x37c >>> syscall(c068002f,2f,2f,0,0) at syscall+0x217 >>> Xint0x80_syscall() at Xint0x80_syscall+0x1d >>> --- syscall (54), eip = 0x284e7b1b, esp = 0xbfbf5dfc, ebp = 0xbfbf5e18 --- > > This is seriously wierd. channel.c:1069 is in chn_setblocksize(), and > it is locking the play channel lock, as one would expect. The > sndbuf_remalloc() call should be calling chn_unlock() and chn_lock() on > the same play channel lock, but it sure looks like it is trying to lock > the record channel lock. > >> Also, I'm getting following warning with sound related code path. >> >>> malloc() of "4096" with the following non-sleepable locks held: >>> exclusive sleep mutex pcm0:play:0 (pcm play channel) r = 0 (0xc31ca140) locked @ dev/sound/pcm/channel.c:1069 >>> malloc() of "4096" with the following non-sleepable locks held: >>> exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc31ca2c0) locked @ dev/sound/pcm/dsp.c:213 >>> malloc() of "4096" with the following non-sleepable locks held: >>> exclusive sleep mutex pcm0:record:0 (pcm record channel) r = 0 (0xc31b6ec0) locked @ dev/sound/pcm/dsp.c:479 >> >> FYI, I use following sound card build into my note book. >> >> pcm0: <Yamaha DS-1E (YMF744)> port 0xfcac-0xfcaf,0xfc00-0xfc3f mem 0xfecf0000-0xfecf7fff irq 9 at device 9.0 on pci0 >> pcm0: <Asahi Kasei AK4543 AC97 Codec> > > My suspicion is that there are problems with locking of the record > channel, though I can't explain why the locking problems are reported > like they are above instead of problems pointing directly to > dsp_ioctl(). Can you try the patch below? Be warned that I don't have the appropriate combination of hardware and software to really exercise it. I know that it won't fix the problem of >>> malloc() of "4096" with the following non-sleepable locks held: >>> exclusive sleep mutex pcm0 (sound cdev) r = 0 (0xc31ca2c0) locked @ dev/sound/pcm/dsp.c:213 but I'm hoping the other problems go away.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402171641.i1HGf07E050235>