Re: Gkrellmd prompts "sleeping thread"

On Sunday 07 October 2007 07:06:21 pm Michael Butler wrote:
> For whatever reason I seem to be able to reliably reproduce a panic on
> -current by running gkrellmd on one of my machines yet another (this
> one) has no problems at all :-(
> 
> Any thoughts welcome ..
> 
> mail# more info.0
> Dump header from device /dev/ar0s1b
>   Architecture: i386
>   Architecture Version: 2
>   Dump Length: 97525760B (93 MB)
>   Blocksize: 512
>   Dumptime: Sun Oct  7 17:15:51 2007
>   Hostname: mail.auburn.protected-networks.net
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 7.0-CURRENT #1: Thu Oct  4 22:33:53 EDT 2007
>     root_at_mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN
>   Panic String: sleeping thread
>   Dump Parity: 3933400909
>   Bounds: 0
>   Dump Status: good
> 
> mail# kgdb /boot/kernel.old/kernel vmcore.0
> kgdb: kvm_nlist(_stopped_cpus):
> kgdb: kvm_nlist(_stoppcbs):
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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-marcel-freebsd".
> (no debugging symbols found)...Attempt to extract a component of a value
> that is not a structure pointer.
> (kgdb) bt
> #0  0xc059f32b in doadump ()
> #1  0xc059f7a4 in boot ()
> #2  0xc059fb18 in panic ()
> #3  0xc05cf172 in propagate_priority ()
> #4  0xc05cfa66 in turnstile_wait ()
> #5  0xc0593f11 in _mtx_lock_sleep ()
> #6  0xc0676011 in intsmb_rawintr ()
> #7  0xc0583a4d in ithread_loop ()
> #8  0xc0580774 in fork_exit ()
> #9  0xc07058a0 in fork_trampoline ()

Can you make sure you have DDB in your kernel and get the full console 
messages when it panics?  It will include the stack trace for the offending 
thread.  But actually, try this patch:

Index: intpm.c
===================================================================
RCS file: /usr/cvs/src/sys/pci/intpm.c,v
retrieving revision 1.39
diff -u -r1.39 intpm.c
--- intpm.c     19 Apr 2007 17:14:06 -0000      1.39
+++ intpm.c     11 Oct 2007 20:25:52 -0000
_at__at_ -436,7 +436,7 _at__at_
                /* So that it can use device during device probe on SMBus. */
                return (intsmb_stop_poll(sc));

-       error = tsleep(sc, PWAIT | PCATCH, "SMBWAI", hz / 8);
+       error = msleep(sc, &sc->lock, PWAIT | PCATCH, "SMBWAI", hz / 8);
        if (error == 0) {
                status = bus_read_1(sc->io_res, PIIX4_SMBHSTSTS);
                if (!(status & PIIX4_SMBHSTSTAT_BUSY)) {


-- 
John Baldwin