From owner-freebsd-current@FreeBSD.ORG Wed Apr 26 11:24:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 011CD16A403 for ; Wed, 26 Apr 2006 11:24:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A104B43D45 for ; Wed, 26 Apr 2006 11:24:28 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 167D246D64; Wed, 26 Apr 2006 07:24:28 -0400 (EDT) Date: Wed, 26 Apr 2006 12:24:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <444F4BE4.2070004@samsco.org> Message-ID: <20060426122244.E93543@fledge.watson.org> References: <200604260045.32557.mistry.7@osu.edu> <20060426093356.V93543@fledge.watson.org> <444F4BE4.2070004@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: panic: mutex Giant not owned at /usr/src/sys/cam/cam_xpt.c:4837 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 11:24:29 -0000 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 to continue, or q 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