From owner-freebsd-amd64@FreeBSD.ORG Thu Feb 24 08:33:13 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 770E416A4CE for ; Thu, 24 Feb 2005 08:33:13 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D1E343D2D for ; Thu, 24 Feb 2005 08:33:13 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 924A1C9BEE for ; Thu, 24 Feb 2005 00:33:12 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21836-04 for ; Thu, 24 Feb 2005 00:33:10 -0800 (PST) Received: from [192.168.15.103] (dsl081-069-073.sfo1.dsl.speakeasy.net [64.81.69.73]) by mail.trippynames.com (Postfix) with ESMTP id 5E562C9BE7 for ; Thu, 24 Feb 2005 00:33:10 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050222195750.GA40969@sean.gigave.com> References: <20050221211056.GC826@sean.gigave.com> <421ACBFF.6030606@samsco.org> <20050222195750.GA40969@sean.gigave.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8c775b6238bd39c25bc895142ca5190c@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 24 Feb 2005 00:33:09 -0800 To: amd64@freebsd.org X-Mailer: Apple Mail (2.619.2) Subject: vrele: negative ref cnt (was: Re: Crash dumps not working correctly for amd64?) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 08:33:13 -0000 So, buried in the last email I sent out was the actual panic string for the dumps I've been having. Has anyone else seen this or is this a known problem? I haven't been able to extract a correct dump yet. I just dd(1)'ed the swap partition hoping that next time it dumps, there will be a clean dump that I can extract a backtrace from, however I'm not too hopeful that this will work as a fix for me. Regardless, I'd assume that twa(1) + amd64 work fine together? This crash seems to emanate from the file system code so I doubt it's driver related. Anyone know what could lead to this? Feel free to send me in the direction of fs@ if I'm not the only one having this problem or that this isn't amd64 specific. Right now I can generally trigger this once every 24hrs, so it's becoming something of a problem for me and without a valid dump, I'm not sure where to begin. -sc > # savecore -vf > bounds number: 9 > checking for kernel dump on device /dev/da0s1b > mediasize = 3221225472 > sectorsize = 512 > magic mismatch on last dump header on /dev/da0s1b > forcing magic on /dev/da0s1b > savecore: first and last dump headers disagree on /dev/da0s1b > savecore: reboot after panic: vrele: negative ref cnt > Checking for available free space > Dump header from device /dev/da0s1b > Architecture: amd64 > Architecture Version: 16777216 > Dump Length: 2146631680B (2047 MB) > Blocksize: 512 > Dumptime: Thu Dec 16 03:06:24 2004 > Hostname: nfs.example.com > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 5.3-STABLE #1: Wed Dec 8 22:20:38 PST 2004 > root@nfs.example.com:/usr/obj/usr/src/sys/NFS > Panic String: vrele: negative ref cnt > Dump Parity: 1999448632 > Bounds: 9 > Dump Status: bad > savecore: writing core to vmcore.9 > 2146631680 -- Sean Chittenden