Re: CVS commit: src/sys/arch

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Jul 03, 2011 at 06:49:11PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> > On Sun, Jul 03, 2011 at 06:09:10PM +0100, Mindaugas Rasiukevicius wrote:
> > > > I also don't think we did reach a consensus about this either.
> > > 
> > > Well, I object on adding only DIAGNOSTIC, without DEBUG and DDB trace
> > > enabled, as it is counter productive to the idea to gather more info.
> > 
> > I can't see how DEBUG can give more infos for KASSERT().
> > I can see how DDB trace will hide usefull infos from KASSERT().
> > 
> > > LOCKDEBUG would be useful as well, but its very significant effect to
> > > performance can be understood.
> > > 
> > > Also, it seems that nobody disagreed on enabling DDB trace (as well as
> > > adding DEBUG option).  What makes you think that we did not reach the
> > > consensus?
> > 
> > I did agree at fisrt, but then I sent
> > http://mail-index.netbsd.org/tech-kern/2011/06/17/msg010736.html
> 
> There are over a hundred KDASSERT()s and plenty #ifdef DEBUG checks.

Maybe, but what I've seen up to now is KASSERT() which fires up in Xen
and not in native kernel, because Xen has DIAGNOSTIC and native doesn't.
So clearly DIAGNOSTIC is missing in native kernel in the developement tree.

Maybe DEBUG would be usefull to have too, but I don't know what its
implications are.

> Crash reports without backtrace - that is very often useless, and we do

A panic message (especually from KASSERT which gives the exact place)
is more usefull than the tail of a backtrace.
Xen has trace enabled by default, and it's a problem when the
console is VGA (but as ddb.onpanic is now 0 it doen't cause a problem
any more).

> receive such reports in time, where we need to ask users to reproduce
> it again and collect more information.  Naturally, we cannot expect our
> users/admins to be fluent in DDB, but collecting more information is a
> key in debugging more complex bugs, and backtrace is a bare minimum.
> 
> I think the change is half-baked and should we be reverted until we
> reach the agreement on tech-kern@.

I can't see why it should be reverted if it's a step in the direction
we want to go.

> 
> > > > With DDB on panic you don't get a core dump, you just see the system
> > > > hang if running X11.
> > > > With trace (assuming you're not running X11), you have the usefull
> > > > panic message scroll away on a standard VGA screen.
> > > 
> > > Again, "call ddb_vgapost" was proposed.  You can still coredump, either
> > 
> > what will this do on a serial console ?
> 
> How is it related to serial console?

Most of my systems have serial console. What does ddb_vgapost do on
a system which doens't have a VGA console ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--