From owner-freebsd-current@FreeBSD.ORG  Tue Mar 16 08:21:52 2004
Return-Path: <owner-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 9200E16A4CE
	for <freebsd-current@freebsd.org>;
	Tue, 16 Mar 2004 08:21:52 -0800 (PST)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by mx1.FreeBSD.org (Postfix) with SMTP id AD04343D45
	for <freebsd-current@freebsd.org>;
	Tue, 16 Mar 2004 08:21:51 -0800 (PST)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa80253@salmon>; 16 Mar 2004 16:21:50 +0000 (GMT)
To: Sven Willenberger <sven@dmv.com>
In-reply-to: Your message of "Tue, 16 Mar 2004 11:00:30 EST."
             <1079452815.23554.69.camel@lanshark.dmv.com> 
X-Request-Do: 
Date: Tue, 16 Mar 2004 16:21:49 +0000
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID: <200403161621.aa80253@salmon.maths.tcd.ie>
cc: dwmalone@maths.tcd.ie
cc: freebsd-current@freebsd.org
Subject: Re: kmem_map too small, revisited 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2004 16:21:52 -0000

> > Another possibility is to add the DDB and DDB_UNATTENDED options
> > to your kernel and record the backtraces when the machine reboots.

> Do I need to define dumpdev in rc.conf as well? Also, after the machine
> reboots after the crash, I can access the kernel dump with DDB by
> dropping to debug mode? (via the sysctl or keyboard per the handbook and
> assuming the DDB_UNATTENDED preserves the information upon reboot into
> multi-user)

For this type of panic, I don't think setting dumpdev will be useful
(at least initially). Adding DDB to the kernel will produce a
backtrace (ie. the list of functions being called) at the time the
machine dies. You'll still have to take down this information by
hand - DDB_UNATTENDED just tells the machine to reboot rather than
dropping fully into the debugger. This is useful if the machines
are in production and you need them to be up-and-running again without
human intervention.

	David.