https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195262
Bug ID: 195262
Summary: [lor] Possibly two LORs: entropy harvest mutex and
scrlock, and entropy harvest mutex and sleepq chain
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: Needs Triage
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: ell...@panasas.com
I get the following output from WITNESS detecting a LOR for possibly two LORs
relating to the harvest mutex on bootup. This is an almost perfectly standard
boot of 10.1-RELEASE with the exception that I've enabled WITNESS. Please note
that I have NOT enabled WITNESS_SKIPSPIN. That seems to be the widely accepted
band-aid for issues that look like this. Such a solution, if you can call it
such, is not acceptable at my company. I'm happy to do the fix for this bug,
but I wanted to open this at least so it's on people's radars, and to solicit
feedback from the community if this is an absolutely unavoidable LOR (and why
we can't just mark the lock BLESSED if so).
Selected output from my VM running 10.1 with WITNESS:
<snip>
atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0
Event timer "RTC" frequency 32768 Hz quality 0
ppc0: cannot reserve I/O port range
Timecounters tick every 10.000 msec
pcm0: measured ac97 link rate at 30976 Hz
lock order reversal:
lock order reversal:
1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @
/usr/src/sys/dev/random/random_harvestq.c:198
2nd 0xffffffff813b6208 scrlock (scrlock) @
/usr/src/sys/dev/syscons/syscons.c:2682
KDB: stack backtrace:
#0 0xffffffff808b6c40 at kdb_backtrace+0x60
#1 0xffffffff808ca56a at witness_checkorder+0xb8a
#2 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#3 0xffffffff806db7d0 at sc_puts+0xb0
#4 0xffffffff806dee55 at sc_cnputc+0xe5
#5 0xffffffff80842c7f at cnputc+0x7f
#6 0xffffffff80842f18 at cnputs+0x58
#7 0xffffffff808bba57 at putchar+0x137
#8 0xffffffff808ba7ea at kvprintf+0xda
#9 0xffffffff808bc057 at vprintf+0x87
#10 0xffffffff808bbfc3 at printf+0x43
#11 0xffffffff808ca35e at witness_checkorder+0x97e
#12 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#13 0xffffffff8088a29b at msleep_spin_sbt+0x5b
#14 0xffffffff8063f0b8 at random_kthread+0x78
#15 0xffffffff80858b11 at fork_exit+0x71
#16 0xffffffff80c2143e at fork_trampoline+0xe
1st 0xffffffff81633d88 entropy harvest mutex (entropy harvest mutex) @
/usr/src/sys/dev/random/random_harvestq.c:198
2nd 0xffffffff81424bb8 sleepq chain (sleepq chain) @
/usr/src/sys/kern/subr_sleepqueue.c:240
KDB: stack backtrace:
#0 0xffffffff808b6c40 at kdb_backtrace+0x60
#1 0xffffffff808ca56a at witness_checkorder+0xb8a
#2 0xffffffff808714ae at __mtx_lock_spin_flags+0x4e
#3 0xffffffff8088a29b at msleep_spin_sbt+0x5b
#4 0xffffffff8063f0b8 at random_kthread+0x78
#5 0xffffffff80858b11 at fork_exit+0x71
#6 0xffffffff80c2143e at fork_trampoline+0xe
usbus0: 12Mbps Full Speed USB v1.0
ugen0.1: <Apple> at usbus0
uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <VBOX HARDDISK 1.0> ATA-6 device
ada0: Serial Number VB96c35aac-e62dbb5d
ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes)
ada0: 20480MB (41943040 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
<snip>
I have it panicking into DDB now, so if there are suggestions on best
strategies for tackling LORs I'm all ears.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
