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 also, there is an upgrade script which disable ddb.onpanic and I'm not sure where it is (I just know it's disabling it every time I upgrade and I have to remember re-enabling it). Also, for this KASSERT() is not different from other panic, adding back DIAGNOSTIC doesn't change anything in this area. I think it's a separate issue. > > > 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 ? Again this is not different from other panics we may have in the kernel. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --