On Tue, 13 Jan 2009, Pete French wrote:
Features like WITNESS and INVARIANTS may change the timing of the kernel
making certain race conditions less likely; I'd run with them for a bit and
see if you can reproduce the hang with them present, as they will make
debugging the problem a lot easier, if it's possible.
Uh, the above *was* me reproducing the hang with them present ;-)) It quite
happily hangs with thoise things in the kernel - indeed the next hang was
immediately after I rebooted the machine. But even with WITNESS and
INVARIANTS and all the rest it does not drop to a debugger, it simply locks
up.
That machine is currently turned off, but still has 7.1 installed. What
would you like me to try now ? I have a lockup I can reproduce pretty
reliably now (just wait and it will always lock up). I also found that my
other 7.1 box locks up fairly reliably when doing a buildworld.
The only similarily between these two machines and the ones which dont lock
up is that these are serving DNS. The others don't. Note that all the
hardware is identical, as is the installed software and the configuration.
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. For somewhat complicated reasons to
explain, serial breaks are more effective at getting into the debugger, so are
preferable -- also because you can more easily log output from the debugger.
If you are able to get into the debugger, the normal commands would be most
helpful, especially if you can log the results:
ps
show lockedvnods
show alllocks
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"
