Subject: Re: crash dumps on NetBSD/alpha?
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>
List: port-alpha
Date: 09/29/1996 00:40:44
Jason Thorpe wrote:
> On Mon, 23 Sep 1996 09:57:01 -0700 
>  templin@nas.nasa.gov (Fred L. Templin) wrote:
> 
>  > 	1. Is it even possible to save a crash dump image on the
>  > 	   NetBSD Alpha port? If so, is it possible to analyze the
>  > 	   dump using some sort of debugging tool?
> 
> To my knowledge, NetBSD/alpha doesn't yet support crash dumps.  I'm
> not exactly sure why ... Chris will have to answer that :-)

because nobody's written the code yet.  It shouldn't be too hard to
get the kernel to write out the relevant data, and indeed, now that
i've gotten other stuff (e.g. kvm_mkdb) out of the way in the post-1.2
tree, i'll add this to my projects list.


>  > 	2. Is there a way to disable auto-rebooting, so that I can
>  > 	   at least glean the panic string when the system goes
>  > 	   belly-up?
> 
> In the PROM, you could set the "auto action" (I forget the exact
> PROM environment variable) to "halt" ... that should keep it from
> doing an automatic reboot...

Actually, if you're talking about a multia or any other machine with
TGA video, it won't be that easy because of the video hack that makes
the screen unreadable when you get back to the console.  If you're
talking about a VGA console, well, you might have a hope but things
will probably have scrolled off your screen...


There are two ways around this:

	(1) use dmesg to look at the kernel message buffer.  There
	    _should_ be data there from before the most recent kernel
	    boot.  (If not, it's because you've got a Lot of devices,
	    and i tried to fix that -- look for a PR i submitted a
	    while back ... that got nowhere.)

	(2) compile your kernel (especially your machdep.o) with
	    'options BOOTKEY'.  That causes the system to prompt
	    for a keypress before halt/reboot.  (It's an
	    alpha-specific option that I added to help me get around
	    exactly this problem for machines that have lots of
	    devices.  8-)
	   
	

chris