Date: Wed, 26 Apr 2006 12:24:28 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/cam/cam_xpt.c:4837 Message-ID: <20060426122244.E93543@fledge.watson.org> In-Reply-To: <444F4BE4.2070004@samsco.org> References: <200604260045.32557.mistry.7@osu.edu> <20060426093356.V93543@fledge.watson.org> <444F4BE4.2070004@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Apr 2006, Scott Long wrote: > Robert Watson wrote: >> >> On Wed, 26 Apr 2006, Anish Mistry wrote: >> >>> #10 0xc04cc002 in panic (fmt=0xc06284f9 "mutex %s not owned at %s:%d") >>> at /usr/src/sys/kern/kern_shutdown.c:549 >>> #11 0xc04c3b43 in _mtx_assert (m=0xc06286ff, what=-1056878592, >>> file=0xc06181c9 "/usr/src/sys/cam/cam_xpt.c", line=4837) >>> at /usr/src/sys/kern/kern_mutex.c:768 >>> ---Type <return> to continue, or q <return> to quit--- >>> #12 0xc0432c65 in xpt_release_devq (path=0x0, count=1, run_queue=1) >>> at /usr/src/sys/cam/cam_xpt.c:4837 >>> #13 0xc043420e in xpt_action (start_ccb=0xc22f9530) >>> at /usr/src/sys/cam/cam_xpt.c:3580 >>> #14 0xc051091b in kern_sendit (td=0xc28f7870, s=4, mp=0xcca4bc6c, >>> flags=0, >>> control=0x0, segflg=3227694719) >>> at /usr/src/sys/kern/uipc_syscalls.c:775 >>> #15 0xc0511965 in sendit (td=0xc28f7870, s=4, mp=0xcca4bc6c, flags=0) >>> at /usr/src/sys/kern/uipc_syscalls.c:715 >> >> Something really nasty happened to the stack between frame 14 and frame 13. >> The above code path Should Never Happen. The CAM bit is consistent with >> itself, and with the panic message, and the socket bit is consistent with >> itself. That leaves a question about what happened in between. Did you >> try running 'trace' under DDB? If so, can you use dmesg on the core dump >> to see if the DDB trace differs from the gdb trace? > > There are quite a few missing frames from CAM-land. I'm sort of vaguely hoping that DDB will give a better stack trace, but I'm not sure there's much hope. It seems like perhaps the stack has gotten quite hosed. I guess the missing CAM frames couldn't be put down to inlined frames not showing up in DDB? It sort of looks like we have the top of one stack, and the bottom of another stack. Until you get to kern_Sendit(), it all sounds pretty good from the system call perspective. It would be interesting to look higher up the thread and confirm whether this system call is, in fact, sendto() or something along those lines. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060426122244.E93543>