From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 18:18:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70F4C417 for ; Wed, 25 Feb 2015 18:18:54 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 103FCF76 for ; Wed, 25 Feb 2015 18:18:53 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1PIJWLG047584 for ; Wed, 25 Feb 2015 10:19:32 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> References: <8c86fda8d0fc741ea9b2e2d406f9fd27@ultimatedns.net>, <0265b4d2825c93a9a11e930de9751974@ultimatedns.net> From: "Chris H" Subject: Re: bombarded with LOR's with recent install Date: Wed, 25 Feb 2015 10:19:32 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <60a188b7861637d4bb7085b06f506a84@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 18:18:54 -0000 On Wed, 25 Feb 2015 09:42:54 -0800 "Chris H" wrote > On Wed, 25 Feb 2015 08:56:14 -0800 "Chris H" 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@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) @ /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 > > > > -- > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"