cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 swtch.s src/sys/kern kern_shutdown.c src/sys/sys systm.h

[Robert Watson]

On Tue, 20 Jan 2004, M. Warner Losh wrote:

> : Actually, I was having a very similar conversation with Bill Paul this
> : afternoon.  We were discussing dropping a copy of the kernel message
> : buffer onto the header of swap space on panic, if possible, and then
> : dropping them in /var/log/crash.log for management by newsyslog.  Then the
> : natural response to "My machine spontaneously reboots" becomes "Look for
> : something recent in /var/log/crash.log", as opposed to "You'll need to
> : enable crash dumps, set up a serial console", etc.  It's also something we
> : could turn on by default, as opposed to crash dumps, which would otherwise
> : consume of alot of disk space.
> 
> I assume you are talking about reading them out of swap space on boot so
> you'd see something like the following in your logs: 
> 
> <date-time> foo: first reboot after kernel panic
> <insert-panic-message-here>
> 
> Right?  Then the message would be zeroed out, so you don't get it on a
> normal reboot, right? 

Yes, exactly.  It would include any recent information in the message
buffer, including unusual printfs, panic messages, etc.  Depending on how
we arranged it, presumably it could even include output from the DDB
session if DDB was compiled in.  My only real concern is making sure that
if things go wrong in writing it out, we don't stall the reboot following
the panic.  It used to be the case, for example, that we would panic
during a dump, and that would not only lose our dump, but also potentially
hang the console.  There is more risk associated with generating the
message buffer dump as opposed to simply resetting, but it might well pay
off (and could easily be configurable with a default depending on the
usual failure mode). 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research