Date: Mon, 09 Feb 2004 01:53:39 -0600 From: Richard Todd <rmtodd@ichotolot.servalan.com> To: freebsd-current@freebsd.org Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131 Message-ID: <E1Aq6Ed-0006OA-ID@servalan.servalan.com>
next in thread | raw e-mail | index | archive | help
My system is a dual PII/400 system with Tyan motherboard and onboard
Soundblaster-compatible audio ("sbc" driver). Saturday night I upgraded
from a Jan. 17 vintage -current kernel to the then-current -current kernel
and found that the new kernel panics upon any attempt by a sound-using
program to open /dev/dsp with this panic:
panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131
I've appended a gdb backtrace to the end of this message. After much
fiddling about doing cvs updates searching between Jan. 17 and now to
find when this broke in -current, I found that the following change in
-current seems to be responsible. Kernels from before this commit work,
kernels after it fail with the aforementioned panic...
--------------------------------------------------------------------
truckman 2004/01/28 00:02:15 PST
FreeBSD src repository
Modified files:
sys/dev/sound/pcm buffer.c buffer.h channel.c channel.h
dsp.c sound.c sound.h vchan.c
Log:
Change KASSERT() in feed_vchan16() into an explicit test and call to
panic() so that the buffer overflow just beyond this point is always
caught, even when the code is not compiled with INVARIANTS.
[... rest of lengthy commit message deleted, except for this -- RMT ...]
Change the locking code to avoid the need for MTX_RECURSIVE mutexes.
[... more commit message deleted -- RMT ...]
--------------------------------------------------------------------
I note that the commit message said that the locking code was changed to
avoid the need for MTX_RECURSIVE mutexes; I'm not an expert by any means
on this mutex stuff, but it sounds like the panic message means that
something in the sbc code *thought* it was entitled to recurse on that
mutex, and ran into trouble because the mutexes aren't declared as recursive
any more.
Anyway, here's the debugger info as requested.
Script started on Mon Feb 9 00:13:27 2004
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131
panic messages:
---
---
Reading symbols from /usr/src/sys/i386/compile/ICHOTOLOTSMP/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for /usr/src/sys/i386/compile/ICHOTOLOTSMP/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from /usr/src/sys/i386/compile/ICHOTOLOTSMP/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for /usr/src/sys/i386/compile/ICHOTOLOTSMP/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
#0 doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc06853d3 in boot (howto=256) at ../../../kern/kern_shutdown.c:374
#2 0xc0685809 in __panic () at ../../../kern/kern_shutdown.c:552
#3 0xc067b74f in _mtx_lock_sleep (m=0xc5080340, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:479
#4 0xc067b26f in _mtx_lock_flags (m=0xc5080340, opts=0,
file=0xc08d4656 "../../../dev/sound/isa/sbc.c", line=131)
at ../../../kern/kern_mutex.c:251
#5 0xc05bad4c in sbc_lock (scp=0x0) at ../../../dev/sound/isa/sbc.c:131
#6 0xc05b83dc in sb_lock (sb=0x0) at ../../../dev/sound/isa/sb16.c:123
#7 0xc05b87a4 in sb_reset_dsp (sb=0xc50a7600)
at ../../../dev/sound/isa/sb16.c:269
#8 0xc05b8f6f in sb_setup (sb=0x83) at ../../../dev/sound/isa/sb16.c:550
#9 0xc05b93f5 in sb16chan_trigger (obj=0xc505bcb0, data=0xc50a762c, go=0)
at ../../../dev/sound/isa/sb16.c:705
#10 0xc05e1aca in chn_trigger (c=0x0, go=1) at channel_if.h:100
#11 0xc05e04e7 in chn_start (c=0xc50a7480, force=0)
at ../../../dev/sound/pcm/channel.c:523
#12 0xc05dfe3e in chn_write (c=0xc50a7480, buf=0xe2671c80)
at ../../../dev/sound/pcm/channel.c:321
#13 0xc05e2d66 in dsp_write (i_dev=0xc50a5800, buf=0x0, flag=589825)
at ../../../dev/sound/pcm/dsp.c:435
#14 0xc06489c3 in spec_write (ap=0xe2671be4)
at ../../../fs/specfs/spec_vnops.c:315
#15 0xc06481a8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:122
#16 0xc06f0ba2 in vn_write (fp=0xc55c8f68, uio=0xe2671c80,
active_cred=0xc52d3880, flags=0, td=0xc523c150) at vnode_if.h:432
#17 0xc06b203b in dofilewrite (td=0xc523c150, fp=0xc55c8f68, fd=0,
buf=0x8d75e00, nbyte=0, offset=0, flags=0) at ../../../sys/file.h:249
#18 0xc06b1e5e in write (td=0xc523c150, uap=0xe2671d14)
at ../../../kern/sys_generic.c:334
#19 0xc08741d0 in syscall (frame=
{tf_fs = 47, tf_es = 542703663, tf_ds = -1078001617, tf_edi = 10000, tf_esi = 9551, tf_ebp = -1077945940, tf_isp = -496558732, tf_ebx = 1792, tf_edx = 148328448, tf_ecx = 15, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 542592036, tf_cs = 31, tf_eflags = 659, tf_esp = -1077946064, tf_ss = 47})
at ../../../i386/i386/trap.c:1008
#20 0xc085fabd in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
(kgdb) q
Script done on Mon Feb 9 00:14:36 2004
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Aq6Ed-0006OA-ID>