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

[Nate Lawson]

On Wed, 21 Jan 2004, Greg 'groggy' Lehey wrote:
> On Tuesday, 20 January 2004 at 11:31:03 -0800, Nate Lawson wrote:
> > * GDB over Ethernet
>
> We have GDB over firewire.  Ethernet would be nice too, but firewire
> actually does more.  Take a look at gdb(4) (new man page).

I'm glad to have this.  More machines have ethernet than firewire ports
though.

> > We don't need file/line added to the panic message since panic
> > messages are unambiguous.
>
> You still need to grep for them.

There are basically two kinds of panics:  assertions and page faults.
Assertions, whether KASSERT or explicit checks/panic calls, give a unique,
easily identified message ("foo driver: invalid mbuf length, %d").  If
this is not obvious enough even without grep, then the panic message
should be fixed.  There is no difference between "vi +line file.c" and
"vi file.c /msg", hence phk's commit is not useful in this case.

Page faults are much harder to track down from the start.  You find
whether or not it was a NULL pointer, the curproc, and PC.  So the next
step is to have them recompile with options DDB or preferably -g and type
"tr" at the DDB prompt.  The changes to panic do not help this case at all
since you get the file and line of the page fault handler.

I would have gotten 100x more value from making options DDB the default in
GENERIC (at least until we branch -stable) and having all page faults
generate a backtrace.  This is a 1 line change that would save hours, not
minutes, of roundtrip email.  Look at reports of panics in the
freebsd-current@ archives and see how many result in a request for a
backtrace.

-Nate