On Wed, 14 Jan 2009, Pete French wrote:
If you have BREAK_TO_DEBUGGER compiled into the kernel, then try pressing
ctrl-alt-break on the console to see if you can drop into the debugger, or
issue a serial break on a serial console.
Well, I added BREAK_TO_DEBUGGER to the kernel config I had which contained
all the other stuff (WITNESS etc...). The end result...
...it no longer crashes :-(
I am not sure what to make of that! Wat could adding this to the kernel
possibly do which would make my problems go away ? Should I try just adding
this option to my GENERIC kernel and seeing if that also gives me something
stable ?
Yeah, that is unexpected -- the BREAK_TO_DEBUGGER path should have almost know
effect on control flow, unlike, say, WITNESS, which significantly distorts
timing. Is there any chance you picked up any of the recent fixes that went
into RELENG_7 without noticing, and that perhaps one of those did it? With
regard to what to do: if you didn't pick up a fix without noticing, yeah, I
think it's worth testing the hypothesis that BREAK_TO_DEBUGGER fixed (or at
least, masked) the problem. Generally with this sort of testing one has to be
pretty rigorous in testing assumptions, because it's easy for changes to sneak
in. Particularly annoying are seemingly innocuous code changes that do things
like slightly rearrange kernel memory.
FWIW, I suspect the various reports we are seeing reflect more than one
problem, and that they must be relatively edge-case individually but reports
of a few problems have lead to more "coming out of the woodwork". Obviously,
the problems are not edge-case to the people experiencing them...
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
