Re: panic upon kldunload snd_ich (lor # 159)

From: Ben Kaduk <minimarmot_at_gmail.com>
Date: Tue, 13 Sep 2005 19:35:50 +0000
On 9/13/05, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
> 
> On Mon, Sep 12, 2005 at 05:27:00AM +0000, Ben Kaduk wrote:
> > On 9/12/05, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
> > >
> > > On Mon, Sep 12, 2005 at 04:04:48AM +0000, Ben Kaduk wrote:
> > > > Hi everyone,
> > > >
> > > > I see that this panic is caused by lor #159
> > > > http://sources.zabbadoz.net/freebsd/lor.html#159
> > > > but I figured I'd report it to see if it will help anyone
> > > >
> > > > Booting to single user and issuing:
> > > > # kldload snd_ich
> > > > # kldunload snd_ich
> > > >
> > > > are sufficient to trigger the panic on my system. I know that 
> Alexander
> > > > Leidinger has recently committed some bits to current in the sound 
> code,
> > > but
> > > > it is unclear if it will fix my panic; I'm currently cvsup-ing and
> > > building
> > > > world to find out.
> > > >
> > > > The machine in question is:
> > > >
> > > > bash-2.05b$ uname -a
> > > > FreeBSD prolepsis.math.uiuc.edu <http://prolepsis.math.uiuc.edu> <
> http://prolepsis.math.uiuc.edu> <
> > > http://prolepsis.math.uiuc.edu>
> > > > 7.0-CURRENTFreeBSD
> > > > 7.0-CURRENT #9: Thu Aug 25 06:22:00 UTC 2005
> > > > kaduk_at_prolepsis.math.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS
> > > > i386
> > > >
> > > > As shown below, I have a core to play with, so if this needs fixing,
> > > tell me
> > > > what I can do to help.
> > > >
> > > I think the LOR you seen is not cause of panic. As you've got core, 
> would
> > > you please give us full back-trace with symbol information?
> > > See
> > > 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-kld.htmlformore datils.
> > > And make sure to rebuild sound driver module with debugging 
> information
> > > too.
> > > --
> > > Regards,
> > > Pyun YongHyeon
> > >
> > (sorry if this double-sent; gmail timed out)
> >
> >
> > Thanks for the link, Pyun. I think I found the right snd_ich.ko.debug
> > (luckily I got this before my buildworld finished and I nuked the old
> > modules), and this is all I can get:
> >
> > (kgdb) bt full
> > #0 doadump () at pcpu.h:165
> > No locals.
> > #1 0xc04492fa in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
> > dummy4=0xef8fca38 " Tt?") at /usr/src/sys/ddb/db_command.c:486
> > fn_addr = -1068258876
> > args = {0, -275789308, -1066987413, -1065742880, 28, -275789308,
> > -1069241393, 32, -1066323808, 2}
> > nargs = 0
> > retval = 544870080
> > t = 0
> > #2 0xc04490a4 in db_command (last_cmdp=0xc0744b24, cmd_table=0x0,
> > aux_cmd_tablep=0xc070d9e4, aux_cmd_tablep_end=0xc070d9e8)
> > at /usr/src/sys/ddb/db_command.c:401
> > cmd = (struct command *) 0xc0713220
> > t = 0
> > modif = "
> > 
> Tt?\000\000\000\000T?\217?\r\000\000\000?>{?\r\000\000\000\001\000\000\000t?\217?\026ðh??\rz?\aK\000
> > d?{? \206y? Tt?x\000\000\000
> > 
> Tt?\000\000\000\000\230?\217?\037´D?Y§n?Ø°D?\000\000\000\000\020\000\000\000\000\000\000\000
> > Tt??§D? Tt?ØKt?x\000\000\000??\217?"
> > addr = 0
> > count = 1999
> > have_addr = 0
> > result = 0
> > ---Type <return> to continue, or q <return> to quit---
> > #3 0xc0449195 in db_command_loop () at /usr/src/sys/ddb/db_command.c:452
> > No locals.
> > #4 0xc044b039 in db_trap (type=3, code=0) at 
> /usr/src/sys/ddb/db_main.c:221
> > jb = {{_jb = {-275789060, -275789088, -275789008, -1025104320, 0,
> > -1069240360, 0, 0, 0, 0, -275789008, -1068140841}}}
> > prev_jb = (void *) 0x0
> > bkpt = 0
> > #5 0xc055775c in kdb_trap (type=0, code=0, tf=0xef8fcb84)
> > at /usr/src/sys/kern/subr_kdb.c:473
> > handled = -275788924
> > #6 0xc06adfea in trap (frame=
> > {tf_fs = -1066532856, tf_es = 40, tf_ds = -275840984, tf_edi = 1, tf_esi 
> =
> > -1066488724, tf_ebp = -275788852, tf_isp = -275788880, tf_ebx = 
> -275788796,
> > tf_edx = 1, tf_ecx = -1052684288, tf_eax = 18, tf_trapno = 3, tf_err = 
> 0,
> > tf_eip = -1068141358, tf_cs = 32, tf_eflags = 646, tf_esp = -1066481942,
> > tf_ss = -1066490330})
> > at /usr/src/sys/i386/i386/trap.c:601
> > td = (struct thread *) 0xc2e62640
> > p = (struct proc *) 0xc2e61c48
> > sticks = 3226793233
> > i = 0
> > ucode = 0
> > type = 3
> > code = 0
> > ---Type <return> to continue, or q <return> to quit---
> > eva = 0
> > #7 0xc069c18a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> > No locals.
> > #8 0xc06e0008 in ?? ()
> > No symbol table info available.
> > #9 0x00000028 in ?? ()
> > No symbol table info available.
> > #10 0xef8f0028 in ?? ()
> > No symbol table info available.
> > #11 0x00000001 in ?? ()
> > No symbol table info available.
> > #12 0xc06eac6c in ?? ()
> > No symbol table info available.
> > #13 0xef8fcbcc in ?? ()
> > No symbol table info available.
> > #14 0xef8fcbb0 in ?? ()
> > No symbol table info available.
> > #15 0xef8fcc04 in ?? ()
> > No symbol table info available.
> > #16 0x00000001 in ?? ()
> > No symbol table info available.
> > #17 0xc1415000 in ?? ()
> > No symbol table info available.
> > ---Type <return> to continue, or q <return> to quit---
> > #18 0x00000012 in ?? ()
> > No symbol table info available.
> > #19 0x00000003 in ?? ()
> > No symbol table info available.
> > #20 0x00000000 in ?? ()
> > No symbol table info available.
> > #21 0xc05574d2 in kdb_enter (msg=0x0) at cpufunc.h:60
> > No locals.
> > #22 0xc053b25c in panic (fmt=0xc06eac6c "%s (%s): holders or waiters\n")
> > at /usr/src/sys/kern/kern_shutdown.c:537
> > td = (struct thread *) 0xc2e62640
> > bootopt = 256
> > newpanic = 1
> > ap = 0xef8fcc04 "¶\232l??m?? ???$?\217??*?? ½??×m??g\001"
> > buf = "sx_destroy (sndstat): holders or waiters\n", '\0' <repeats 214 
> times>
> > #23 0xc05412e2 in sx_destroy (sx=0xc2dbbda0) at
> > /usr/src/sys/kern/kern_sx.c:96
> > __func__ = "sx_destroy"
> > #24 0xc2db2adb in ?? ()
> > No symbol table info available.
> > #25 0xc2dbbda0 in ?? ()
> > No symbol table info available.
> > #26 0xc2db6dd7 in ?? ()
> > ---Type <return> to continue, or q <return> to quit---
> > No symbol table info available.
> > #27 0x00000167 in ?? ()
> > No symbol table info available.
> > #28 0xef8fcc50 in ?? ()
> > No symbol table info available.
> > #29 0xc052ad83 in linker_file_sysuninit (lf=0x0)
> > at /usr/src/sys/kern/kern_linker.c:238
> > start = (struct sysinit **) 0xc2db2adb
> > stop = (struct sysinit **) 0xc2dbbda0
> > sipp = (struct sysinit **) 0xc2db74c8
> > xipp = (struct sysinit **) 0x0
> > save = (struct sysinit *) 0x0
> >
> >
> >
> >
> > hope this helps; I should be able to get back with info about today's
> > current tomorrow night.
> >
> 
> Would you try attached patch?
> 
> > Ben Kaduk
> 
> --
> Regards,
> Pyun YongHyeon
> 
> 
> 
Pyun,

I was able to try your patch -- it did not apply cleanly, but was simple to 
manually enter.
After building a new kernel, the panic is gone, but the LOR remains -- it 
does seem that they were unrelated.
For the records, the backtrace of the LOR (#159) is:
lock order reversal
1st 0xc1716bc0 pcm0 (sound cdev) _at_ 
/usr/src/sys/modules/sound/sound/../../../de
v/sound/pcm/sound.c:761
2nd 0xc196b540 sndstat (sndstat) _at_ 
/usr/src/sys/modules/sound/sound/../../../de
v/sound/pcm/sndstat.c:256
KDB: stack backtrace:
kdb_backtrace(c06ef80d,c196b540,c1965a62,c1965a62,c1965a6a) at 
kdb_backtrace+0x2
f
witness_checkorder(c196b540,9,c1965a6a,100,c0725260) at 
witness_checkorder+0x68f
_sx_xlock(c196b540,c1965a6a,100,c197a380,c18fca00) at _sx_xlock+0x7f
sndstat_unregister(c171eb00,c197a380,c1965b77,2f9,c171eb00) at 
sndstat_unregiste
r+0x27
pcm_unregister(c171eb00,c761bbfc,c0557f32,c1943820,c171eb00) at 
pcm_unregister+0
x112
ich_pci_detach(c171eb00,c18e0050,c0721ba8,961,c1909ab0) at 
ich_pci_detach+0x13
device_detach(c171eb00,c1942428,c171eb00,c1683400,c194380c) at 
device_detach+0x8
f
devclass_delete_driver(c1683400,c1943820,1,c1716280,c1716280) at 
devclass_delete
_driver+0x8e
driver_module_handler(c1716280,1,c194380c) at driver_module_handler+0xe7
module_unload(c1716280,0,1fb,0,0) at module_unload+0x61
linker_file_unload(c193ca00,0,c06e9d40,327,0) at linker_file_unload+0x89
kern_kldunload(c16ebaf0,5,0,c761bd30,c06afce5) at kern_kldunload+0x96
kldunloadf(c16ebaf0,c761bd04,8,422,2) at kldunloadf+0x2c
syscall(3b,3b,3b,5,bfbfef12) at syscall+0x295
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280b700b, esp = 
0xbfbfe9dc
, ebp = 0xbfbfee48 ---
pcm0: detached


Thanks for fixing this panic

Ben Kaduk
Received on Tue Sep 13 2005 - 17:35:55 UTC

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