Date: Wed, 25 Feb 2015 09:42:54 -0800 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-current@freebsd.org> Subject: Re: bombarded with LOR's with recent install Message-ID: <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> In-Reply-To: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" <bsd-lists@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) @ /usr/src/sys/kern/vfs_mount.c:1229 > 2nd 0xfffff80004caf5f0 devfs (devfs) @ > /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) @ /usr/src/sys/kern/vfs_bio.c:3097 > 2nd 0xfffff80004f28c00 dirhash (dirhash) @ > /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) @ /usr/src/sys/kern/vfs_subr.c:2176 > 2nd 0xfffffe00f72442e0 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:263 > 3rd 0xfffff80004871068 ufs (ufs) @ /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 > > --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0265b4d2825c93a9a11e930de9751974>