[ On Mon, November 24, 1997 at 16:17:57 (-0500), Gordon W. Ross wrote: ]
> Subject: Re: And just how big can it be? (Sun3/50 kernels..)
>
> Not that I've seen.  (Just in the source code.)

I'd send-pr an update for options(4) about this [I think that would be
the logical place to document it, though perhaps it would be good to put
in the GENERIC files too], but until I have a full CVS'ed local source
tree it's difficult for me to make patches.

That reminds me, is 'cc -g' still of any use, esp. for DDB?  Is KGDB of
any use, or even possible?  Shouldn't the stuff about 'gdb -k' be
removed from options(4)?

> Yes, dump saves all of physical RAM.

Is there any (planned?) support for un-tangling swap area stuff in the
kernel debuggers?  I.e. for digging deeper into the state of a process
that's been partially paged out, or even swapped out, from a dump image?
I would think this could be useful, esp. for emulation-related issues.

If so would it make sense to allocate a separate dump device that's just
enough bigger than RAM so that swap could also be preserved across
panics?  (I.e. don't dump to any swap area...)

> The only unusual thing about savecore on the sun3 is that the machine-
> dependent kernel core header has some MMU state needed by libkvm.

Which brings up the issue of how much bigger the dump device must be
than physical RAM.  I've got 48KB of space on the primary dump/swap
device now for a 32MB machine, but I've seen the "WARNING: EOF on dump"
from savecore and now that I've peered at the source the only way I can
see that it could do that is if the dumpsize values got trashed in the
crash or were miscalculated in the first place (unless I've seriously
under-calculated the extra space required for a dump).

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>