From owner-freebsd-current@FreeBSD.ORG Fri Apr 27 23:59:44 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80C8016A402 for ; Fri, 27 Apr 2007 23:59:44 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 66A2913C480 for ; Fri, 27 Apr 2007 23:59:44 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 406811A4D91; Fri, 27 Apr 2007 17:00:12 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AB4865144E; Fri, 27 Apr 2007 19:59:43 -0400 (EDT) Date: Fri, 27 Apr 2007 19:59:43 -0400 From: Kris Kennaway To: Tom Cumming Message-ID: <20070427235943.GA64867@xor.obsecurity.org> References: <20070427012401.GZ2445@obelix.dsto.defence.gov.au> <20070427013742.GA51877@troutmask.apl.washington.edu> <20070427014317.GA17436@xor.obsecurity.org> <20070427030017.GA52347@troutmask.apl.washington.edu> <20070427031124.GA18527@xor.obsecurity.org> <20070427180021.GA57409@xor.obsecurity.org> <20070427222116.GG840@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Peter Jeremy , freebsd-current@freebsd.org, Steve Kargl , Kris Kennaway Subject: Re: Panic on boot. How do I get a kernel dump. 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: Fri, 27 Apr 2007 23:59:44 -0000 On Fri, Apr 27, 2007 at 04:22:48PM -0700, Tom Cumming wrote: > On 4/27/07, Peter Jeremy wrote: > > >1) It is a production server that can't be left down for extended periods. > > > Yup. I.e., the dump provides a snapshot of the full state of the system > at the moment of the panic. This snapshot can be examined at leisure, a > customer could ftp the dump to a qualified engineer, etc. > > 2) It is a remote system without remote console access. > > > .. or number 3) I can use my existing dump analysis tools and scripts to > examine the dump, and I cannot run the scripts from the console prompt. > > Lets put the original question slightly differently: How can the > >kernel state be saved if the kernel crashes before it's possible to > >invoke dumpon(8)? > > > I don't follow the geom code... is there a place in geom where I could put > something like, geom->dumpdev = "mydevice"? > > Or ... > >Since dumpdev is now intertwined with geom and the geom tasting is > >quite late in the boot process, I agree that the current crashdump > >code does not seem amenable to use early in the boot process. > > does this mean even hard coding the dumpdev won't work? If so, then maybe > the, "your sol" statement is correct. Hmm, guess I needed a bigger font :( Kris