Date: Fri, 21 Nov 2014 20:58:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 195262] New: [lor] Possibly two LORs: entropy harvest mutex and scrlock, and entropy harvest mutex and sleepq chain Message-ID: <bug-195262-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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: ellisw@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-195262-8>