Re: bombarded with LOR's with recent install

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.

--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
> 
> --