Re: bombarded with LOR's with recent install

On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" <bsd-lists_at_bsdforge.com> wrote

> On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" <bsd-lists_at_bsdforge.com> wrote
> 
> I see somebody also reported something along these lines, recently;
> http://freebsd.1045724.n5.nabble.com/ufs-devfs-quot-lock-order-reversal-quot-
> on-poweroff-td5989901.html 
>
> But there was no reported resolution.
and again in January, as well.
https://www.mail-archive.com/freebsd-current_at_freebsd.org/msg158784.html

Is there any way to switch off WITNESS, INVARIANTS && SKIPSPIN
in the GENERIC that is installed, outside of building a new
kernel?

--Chris
> 
> --Chris
> 
> > I just wiped a system last night to perform a fresh install
> > from the 11-CURRENT-amd64-20150223 disk1 CD. After the install,
> > and choosing the "reboot system", resulted in a LOR. I wasn't
> > able to capture the output. But I'm still plagued with LOR's.
> > They almost always follow the halt(8) command, and almost
> > always occur during the final stages of the boot. But aren't
> > always restricted to those events. The LOR's output seem
> > indicative of fs related issues. This system has *always*
> > worked w/o fail, and prior to this install, has never
> > indicated hardware issues.
> > Aside from the dmesg(8) attached, here are 2 of the examples.
> > NOTE the numbers, and files are not always the same, from
> > LOR to LOR;
> > 
> > lock order reversal:
> >  1st 0xfffff8000474f7c8 ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1229
> >  2nd 0xfffff80004caf5f0 devfs (devfs) _at_
> > /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfffffe0120c27570 witness_checkorder() at witness_checkorder+0xe45/frame
> > 0xfffffe0120c27600 __lockmgr_args() at __lockmgr_args+0xacf/frame
> > 0xfffffe0120c27730 vop_stdlock() at vop_stdlock+0x3c/frame
> > 0xfffffe0120c27750 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame
> > 0xfffffe0120c27780 _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120c277f0
> > ffs_flushfiles() at ffs_flushfiles+0x113/frame 0xfffffe0120c27860
> > softdep_flushfiles() at softdep_flushfiles+0x273/frame 0xfffffe0120c278d0
> > ffs_unmount() at ffs_unmount+0x81/frame 0xfffffe0120c27930
> > dounmount() at dounmount+0x42c/frame 0xfffffe0120c279b0
> > sys_unmount() at sys_unmount+0x2ec/frame 0xfffffe0120c27ae0
> > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c27bf0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c27bf0
> > --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008990ea, rsp =
> > 0x7ffffff
> > fe348, rbp = 0x7fffffffe460 ---
> > 
> > lock order reversal:
> >  1st 0xfffffe00f749ddc8 bufwait (bufwait) _at_
> >  /usr/src/sys/kern/vfs_bio.c:3097 2nd 0xfffff80004f28c00 dirhash (dirhash)
> >  _at_ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:2
> > 85
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfffffe0120c6d470 witness_checkorder() at witness_checkorder+0xe45/frame
> > 0xfffffe0120c6d500 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0120c6d540
> > ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe0120c6d580
> > ufs_direnter() at ufs_direnter+0x641/frame 0xfffffe0120c6d640
> > ufs_rename() at ufs_rename+0xffe/frame 0xfffffe0120c6d830
> > VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfffffe0120c6d860
> > kern_renameat() at kern_renameat+0x4bc/frame 0xfffffe0120c6dae0
> > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120c6dbf0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120c6dbf0
> > --- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x801ca4d2a, rsp =
> > 0x7ffffff
> > fded8, rbp = 0x7fffffffdee0 ---
> > 
> > and another
> > 
> > lock order reversal:
> >  1st 0xfffff800048979a0 ufs (ufs) _at_ /usr/src/sys/kern/vfs_subr.c:2176
> >  2nd 0xfffffe00f72442e0 bufwait (bufwait) _at_
> > /usr/src/sys/ufs/ffs/ffs_vnops.c:263
> >  3rd 0xfffff80004871068 ufs (ufs) _at_ /usr/src/sys/kern/vfs_subr.c:2176
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfffffe0120ae9e20 witness_checkorder() at witness_checkorder+0xe45/frame
> > 0xfffffe0120ae9eb0 __lockmgr_args() at __lockmgr_args+0xacf/frame
> > 0xfffffe0120ae9fe0 ffs_lock() at ffs_lock+0x84/frame 0xfffffe0120aea030
> > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe0120aea060
> > _vn_lock() at _vn_lock+0x8a/frame 0xfffffe0120aea0d0
> > vget() at vget+0x67/frame 0xfffffe0120aea110
> > vfs_hash_get() at vfs_hash_get+0xdc/frame 0xfffffe0120aea160
> > ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0120aea1f0
> > softdep_sync_buf() at softdep_sync_buf+0xa90/frame 0xfffffe0120aea2d0
> > ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfffffe0120aea350
> > ffs_truncate() at ffs_truncate+0x671/frame 0xfffffe0120aea530
> > ufs_direnter() at ufs_direnter+0x7d1/frame 0xfffffe0120aea5f0
> > ufs_makeinode() at ufs_makeinode+0x5bf/frame 0xfffffe0120aea7b0
> > ufs_create() at ufs_create+0x2d/frame 0xfffffe0120aea7d0
> > VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfffffe0120aea800
> > vn_open_cred() at vn_open_cred+0x2c6/frame 0xfffffe0120aea960
> > kern_openat() at kern_openat+0x257/frame 0xfffffe0120aeaae0
> > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe0120aeabf0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0120aeabf0
> > --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b4c79a, rsp =
> > 0x7ffffff
> > fd598, rbp = 0x7fffffffd670 ---
> > 
> > I *really* need to build/install world/kernel on this
> > box. But am fairly confident that there will be issues
> > as I LOR's to occur during the process.
> > 
> > Any insight || help with this, greatly appreciated.
> > 
> > Thanks!
> > 
> > --Chris
> > 
> > --
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"