Re: Several LOR's with most recent install media

From: Chris H <bsd-lists_at_bsdforge.com>
Date: Fri, 04 Mar 2016 11:31:07 -0800
On Thu, 03 Mar 2016 07:24:11 -0800 "Chris H" <bsd-lists_at_bsdforge.com> wrote

> On Wed, 02 Mar 2016 23:00:44 -0800 "Chris H" <bsd-lists_at_bsdforge.com> wrote
> 
> > On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H" <bsd-lists_at_bsdforge.com> wrote
> > 
> > > Hello all,
> > >  I just finished an install off of the
> > > 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD.
> > > After rebooting to the fresh install; shutting down the system
> > > results in several LOR's. Given so much information is dumped to
> > > screen, and that I no longer have access to the system; How can I
> > > get a copy of the LOR's output? I can capture the screen with my
> > > cell phone. But the information would sure be a lot more valuable
> > > in text form; no? :-)
> > > 
> > > Thanks for any suggestions.
> > > 
> > OK. Just got a couple more while checking out head/ports
> > 
> > Mar  2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K
> > Mar  2 22:12:00 spare kernel: lock order reversal:
> > Mar  2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) _at_
> > /usr/src/sys/kern/vfs_bio.c:3488
> > Mar  2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) _at_
> > /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
> > Mar  2 22:12:00 spare kernel: stack backtrace:
> > Mar  2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
> > Mar  2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
> > Mar  2 22:12:00 spare kernel: #2 0xc0c31a5
> > Mar  2 22:12:00 spare kernel: 1 at _sx_xlock+0x71
> > Mar  2 22:12:00 spare kernel: #3 0xc0ef0b
> > Mar  2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40
> > Mar  2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682
> > Mar  2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb
> > Mar  2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108
> > Mar  2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a
> > Mar  2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31
> > Mar  2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d
> > Mar  2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f
> > Mar  2 22:19:31 spare kernel: lock order reversal:
> > Mar  2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) _at_
> > /usr/src/sys/kern/vfs_subr.c:873
> > Mar  2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) _at_
> > /usr/src/sys/ufs/ffs/ffs_vnops.c:263
> > Mar  2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) _at_
> > /usr/src/sys/kern/vfs_subr.c:2476
> > Mar  2 22:19:31 spare kernel: stack backtrace:
> > Mar  2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
> > Mar  2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
> > Mar  2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57
> > Mar  2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84
> > Mar  2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118
> > Mar  2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96
> > Mar  2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64
> > Mar  2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1
> > Mar  2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44
> > Mar  2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b
> > Mar  2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa
> > Mar  2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26
> > Mar  2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108
> > Mar  2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40
> > Mar  2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94
> > Mar  2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0
> > Mar  2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b
> > Mar  2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e
> > 
> > Sorry for any undesirable line-wraps.
> > I can attache the output, if needed.
> > 
> > Thanks for any help preventing these.
> > 
> OK. Got another one wile checking out /usr/src
> 
> Mar  3 06:45:41 spare kernel: 1st 0xda5fc478 bufwait (bufwait) _at_
> /usr/src/sys/kern/vfs_bio.c:3488
> Mar  3 06:45:41 spare kernel: 2nd 0xcbf89a00 dirhash (dirhash) _at_
> /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
> Mar  3 06:45:41 spare kernel: stack backtrace:
> Mar  3 06:45:41 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
> Mar  3 06:45:41 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
> Mar  3 06:45:41 spare kernel: #2 0xc0c31a51 at _sx_xlock+0x71
> Mar  3 06:45:41 spare kernel: #3 0xc0ef0b70 at ufsdirhash_add+0x40
> Mar  3 06:45:41 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682
> Mar  3 06:45:41 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb
> Mar  3 06:45:41 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108
> Mar  3 06:45:41 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a
> Mar  3 06:45:41 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31
> Mar  3 06:45:41 spare kernel: #9 0xc117d4ed at syscall+0x37d
> Mar  3 06:45:41 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f
> Mar  3 06:50:42 spare kernel: lock order reversal:
> Mar  3 06:50:42 spare kernel: 1st 0xc880ca30 ufs (ufs) _at_
> /usr/src/sys/kern/vfs_subr.c:873
> Mar  3 06:50:42 spare kernel: 2nd 0xda651cd8 bufwait (bufwait) _at_
> /usr/src/sys/ufs/ffs/ffs_vnops.c:263
> Mar  3 06:50:42 spare kernel: 3rd 0xcb3675c0 ufs (ufs) _at_
> /usr/src/sys/kern/vfs_subr.c:2476
> Mar  3 06:50:42 spare kernel: stack backtrace:
> Mar  3 06:50:42 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
> Mar  3 06:50:42 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
> Mar  3 06:50:42 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57
> Mar  3 06:50:42 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84
> Mar  3 06:50:42 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118
> Mar  3 06:50:42 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96
> Mar  3 06:50:42 spare kernel: #6 0xc0cdf2d4 at vget+0x64
> Mar  3 06:50:42 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1
> Mar  3 06:50:42 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44
> Mar  3 06:50:42 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b
> Mar  3 06:50:42 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa
> Mar  3 06:50:42 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26
> Mar  3 06:50:42 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108
> Mar  3 06:50:42 spare kernel: #13 0xc0cbfc40 at bufsync+0x40
> Mar  3 06:50:42 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94
> Mar  3 06:50:42 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0
> Mar  3 06:50:42 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b
> Mar  3 06:50:42 spare kernel: #17 0xc0bead5e at fork_exit+0x7e
> 
> This one looks *very* similar to what I get at shutdown(8). Only it
> is repeated 3 times -- presumably once for each slice (excluding swap).
> 
> Please let me know if you need any more info, or I should blow
> this attempted install away, and wait for another (newer) revision.
> 
Well, it didn't seem adversely affect building/installing world/kernel.
While several LOR's flashed on the screen during the buildworld
session. The results of the installed world/kernel seem to be
unaffected. If nothing else; perhaps the output I've provided above
will somehow be helpful, for removing them (LOR's) in future
versions. :)

--Chris
Received on Fri Mar 04 2016 - 18:31:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC