On 11/22/2014 03:51 PM, Benjamin Kaduk wrote:
On Fri, 21 Nov 2014, Ellis H. Wilson III wrote:
Before I start, and this is mainly geared to my responder Benjamin Kaduk,
based on your response, are you suggesting that the cnputc WITNESS panic you
expected to happen is now completely unavoidable in FreeBSD 10? I.E., is this
a spinlock that WITNESS falls over each time but that is provably deadlock
free that the developers have decided cannot be BLESSED for some reason?
looks to be a better explanation than the previous link I sent ... in
short, console output is hard.
I guess I just can't wrap my head around why we would ever move to a regime
where SKIPSPIN is the default for testing... That just seems like an open
invitation for introducing spinlock regressions.
I don't think anyone made the conscious decision to do that, it just
happened by default as no one spent the time to fix the aforementioned
Moving onto the LORs I'm seeing, a question I have as a newbie to WITNESS
debugging is how exactly to interpret the output if I see a stacktrace and
then a LOR output like the following:
lock order reversal:
1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @
2nd 0xffffffff813b6208 scrlock (scrlock) @
Does this mean WITNESS has already stored an ordering of #1 harvest_mtx then
#2 scp->scr_lock, and somewhere somebody tried to lock scp->scr_lock without
first getting harvest_mtx? Or the reverse (WITNESS previously recorded
scrlock and then harvest and the lines it spit out were the offenders?)
I believe it is the latter (the ordering being printed is the bad one
which caused WITNESS to complain).
Thanks so much for the additional info Ben. This fleshes out the
history of this issue for me significantly. I have filed a bug on this at:
Xin Li was able to identify the ordering that caused the problem and
proposed a possible patch to fix it. I can confirm that now I'm booting
with solely WITNESS (i.e., not WITNESS_SKIPSPIN) without panic.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"