> Lock order reversals are warnings of potential deadlock due to a lock cycle, > but deadlocks may not actually result, either because it's a false positive > (some locking construct that is deadlock free but involves lock cycles), or > because a cycle didn't actually form. The message is suggestive, but if you > have significant system activity after the message, then it may be unrelated.
Its hard to tell in this case as there are no timestamps, so I cant see if there is any activity after the lockup. > 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. I am at a total loss... -pete. _______________________________________________ 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"
