From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 17:52:22 2005 Return-Path: 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 3368616A4CE for ; Thu, 13 Jan 2005 17:52:22 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id AABAC43D46 for ; Thu, 13 Jan 2005 17:52:20 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail invoked by alias); 13 Jan 2005 17:52:19 -0000 Received: from dsl-082-083-167-119.arcor-ip.net (EHLO [192.168.1.4]) (82.83.167.119) by mail.gmx.net (mp023) with SMTP; 13 Jan 2005 18:52:19 +0100 X-Authenticated: #1954550 Message-ID: <41E6B56B.6020207@gmx.de> Date: Thu, 13 Jan 2005 18:52:43 +0100 From: Phil Schulz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041217 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Matthew Sullivan , freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> In-Reply-To: <20050113093955.P12838@carver.gumbysoft.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 13 Jan 2005 17:52:22 -0000 [lost the original mail...] On 01/13/05 18:41, Doug White wrote: > On Thu, 13 Jan 2005, Matthew Sullivan wrote: >>I'm going to have to put this machine into production within the next 7 >>days so any help would be really great, also any extra info anyone >>requires is available. As I said in my last this is 100% reproducable. >>Dumps are not available - calling panic will lock the system solid. >>Calling boot(0) seems to work fine though... When you are in the debugger, can you type "call doadump"? Last time I tried to debug a panic, I've had problems with panics not generating a core dump as well. Calling the doadump() function manually worked, though. I don't know if a dump will get you any further, though. Kind regards, Phil.