kern/62771: attempting to open /dev/dsp (sbc0) panics the kernel.
Richard Todd
rmtodd at servalan.servalan.com
Thu Feb 12 22:20:06 PST 2004
>Number: 62771
>Category: kern
>Synopsis: attempting to open /dev/dsp (sbc0) panics the kernel.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 12 22:20:06 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Richard Todd
>Release: FreeBSD 5.2-CURRENT i386
>Organization:
none
>Environment:
System: FreeBSD ichotolot.servalan.com 5.2-CURRENT FreeBSD 5.2-CURRENT #6: Thu Feb 12 23:16:40 CST 2004 rmtodd at ichotolot.servalan.com:/u2/tmp/src/sys/i386/compile/ICHOTOLOTSMP i386
Dual PII/400 system with Tyan motherboard with onboard
Soundblaster-compatible audio chip:
sbc0: <Creative ViBRA16X> at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 3,1 on isa0
>Description:
After upgrading from a previous (mid-January) kernel to -current
sources, I discovered that the new kernel panics when any sound-using
program opens /dev/dsp with this panic:
panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131
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. Further examination shows that this is the case, as can be
seen from the backtrace. In dev/sound/isa/sb16.c, the sb_setup()
function does a sb_lock(sb) first thing. A few lines down, sb_setup()
calls sb_reset_dsp(), which *also* does a sb_lock(sb), locking the same
mutex recursively and triggering the panic.
GDB trace:
Script started on Thu Feb 12 22:39:59 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 /u2/tmp/src/sys/i386/compile/ICHOTMP/modules/u2/tmp/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for /u2/tmp/src/sys/i386/compile/ICHOTMP/modules/u2/tmp/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from /u2/tmp/src/sys/i386/compile/ICHOTMP/modules/u2/tmp/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for /u2/tmp/src/sys/i386/compile/ICHOTMP/modules/u2/tmp/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 0xc0685813 in boot (howto=256) at ../../../kern/kern_shutdown.c:374
#2 0xc0685c49 in __panic () at ../../../kern/kern_shutdown.c:552
#3 0xc067bb8f in _mtx_lock_sleep (m=0xc5080340, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:479
#4 0xc067b6af in _mtx_lock_flags (m=0xc5080340, opts=0,
file=0xc08d4bb6 "../../../dev/sound/isa/sbc.c", line=131)
at ../../../kern/kern_mutex.c:251
#5 0xc05bafcc in sbc_lock (scp=0x0) at ../../../dev/sound/isa/sbc.c:131
#6 0xc05b865c in sb_lock (sb=0x0) at ../../../dev/sound/isa/sb16.c:123
#7 0xc05b8a24 in sb_reset_dsp (sb=0xc50a7600)
at ../../../dev/sound/isa/sb16.c:269
#8 0xc05b91ef in sb_setup (sb=0x83) at ../../../dev/sound/isa/sb16.c:550
#9 0xc05b9675 in sb16chan_trigger (obj=0xc505bcb0, data=0xc50a762c, go=0)
at ../../../dev/sound/isa/sb16.c:705
#10 0xc05e1d4a in chn_trigger (c=0x0, go=1) at channel_if.h:100
#11 0xc05e0767 in chn_start (c=0xc50a7480, force=0)
at ../../../dev/sound/pcm/channel.c:523
#12 0xc05e00be in chn_write (c=0xc50a7480, buf=0xe2876c80)
at ../../../dev/sound/pcm/channel.c:321
#13 0xc05e2fe6 in dsp_write (i_dev=0xc50a5800, buf=0x0, flag=131073)
at ../../../dev/sound/pcm/dsp.c:435
#14 0xc0648cd3 in spec_write (ap=0xe2876be4)
at ../../../fs/specfs/spec_vnops.c:315
#15 0xc06484b8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:122
#16 0xc06f1052 in vn_write (fp=0xc563561c, uio=0xe2876c80,
active_cred=0xc5a16200, flags=0, td=0xc5963000) at vnode_if.h:432
#17 0xc06b247b in dofilewrite (td=0xc5963000, fp=0xc563561c, fd=0,
buf=0xbfbf0ef0, nbyte=0, offset=0, flags=0) at ../../../sys/file.h:249
#18 0xc06b229e in write (td=0xc5963000, uap=0xe2876d14)
at ../../../kern/sys_generic.c:334
#19 0xc0874650 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = -1077997840, tf_ebp = -1077997880, tf_isp = -494441100, tf_ebx = 4608, tf_edx = 0, tf_ecx = 13, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 538088191, tf_cs = 31, tf_eflags = 518, tf_esp = -1077997908, tf_ss = 47}) at ../../../i386/i386/trap.c:1008
#20 0xc085ff3d in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
(kgdb) q
>How-To-Repeat:
Boot a recent -current kernel on a system with a Soundblaster-compat
sound card and run anything that opens /dev/dsp.
>Fix:
I was able to work around the problem by fiddling
dev/sound/pcm/sound.c to make that mutex declared as recursive again:
--- pcm/sound.c 28 Jan 2004 08:02:15 -0000 1.89
+++ pcm/sound.c 13 Feb 2004 04:48:15 -0000
@@ -75,7 +75,7 @@
m = malloc(sizeof(*m), M_DEVBUF, M_WAITOK | M_ZERO);
if (m == NULL)
return NULL;
- mtx_init(m, desc, type, MTX_DEF);
+ mtx_init(m, desc, type, MTX_DEF | MTX_RECURSE);
return m;
#else
return (void *)0xcafebabe;
However, since the intent of the original Jan. 28 commit was to make
the mutexes *not* recursive, the Right Thing to Do would probably be
to fix the locking in sb16.c to not try and recursively lock instead.
Alas, I don't really know how to do that.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list