[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch
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
There are over a hundred KDASSERT()s and plenty #ifdef DEBUG checks.
Crash reports without backtrace - that is very often useless, and we do
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@.
> > > 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?
Main Index |
Thread Index |