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

[Don Lewis]

On 21 Jan, Bruce Evans wrote:
> On Tue, 20 Jan 2004, Bill Paul wrote:

>> It would save wear and tear on everyone's
>> nerves (_ESPECIALLY_ mine) if they could just send in a traceback
>> rather than developers being forced to do the usual "go back and
>> do nm ${KERNEL} and tell us what you see" exchange.
> 
> This is much more to ask of ordinary users.  The traceback is only
> easy to provide if it is printed to a serial of other external console,
> or recorded on disk, or someone fixes backtrace() and the message
> buffer manages to live across panic reboots.  Otherwise the user has
> to watch the panic and transcribe the data.  This is too much to ask
> for, especially for verbose panic messages with lots of normally-useless
> data like the the trap_fatal() register dump and traces with stack
> frames for recursive panics (and now even line numbers for recursive
> panics).  If the data can be recorded on disk, then panic dumps should
> work and already contain the data (except the implementation of
> backtrace() is of such quality that it doesn't write the data to the
> message buffer).

It would be extremely helpful to preserve the panic message and
(optionally) the backtrace across the reboot.  Crash dumps may not
always be possible for any number of reasons (swap smaller than RAM,
/var/crash too small or overflowing with previous crash dumps, crash
dump takes too long ...).  This is especially true in cases where the
machine crashes and reboots unattended.


>> Could you determine this from the crash dump? Sure -- but do you have
>> any idea how much of a pain in the ass that can be, especially when
>> the crash occurs on a system that isn't yours? By default, crash
>> dumps are as large as physical memory, and most systems now have at
>> least 128MB of RAM. The average user does not know how to analyze
>> a crash dump, which means even if they get one, they won't be able to
>> do anything with it, except send it to me. That means I'll have people
>> throwing 128MB files at me, which I can't even analyze unless I happen
>> to have a system handy running _exactly_ the same kernel as they are.
> 
> I have defense against the large files (a 56K connection :-).  You can
> write a script to run gdb on their crash dump (if they have one) much
> more easily than you can tell them how to run gdb.

Getting a traceback from a crash dump with gdb isn't currently a total
substitute for a traceback from ddb due to the issues that gdb has with
unwinding the stack if it contains a trap frame.  At present ddb does a
better job of pointing out the exact location where the trap occurred.