Re: Seeing lock order reversal

See archives / UPDATING for an explanation.



On 3/18/08, Robert Huff <roberthuff@xxxxxxx> wrote:

Alex Goncharov writes:

I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT.

I updated on Friday.


The very first 8.0 build (this morning) gave me the kernel that didn't
boot. Built it again, finishing about 15 minutes ago. This one
booted all right but I see this in `/var/log/messages':


================================================================================
WARNING: WITNESS option enabled, expect reduced performance.
lock order reversal:
1st 0xc4093e28 devfs (devfs) @
/mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
2nd 0xc4172b54 devfsmount (devfsmount) @
/mnt/wdx/freebsd/8.0/usr/src/sys/fs/devfs/devfs_vnops.c:201
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e2888bbc,c07a70de,c0af8353,c4172b54,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c4172b54,c0ae90df,c0ae90df,c0ae9120,...) at
kdb_backtrace+0x29
witness_checkorder(c4172b54,9,c0ae9120,c9,c7,...) at
witness_checkorder+0x6de
_sx_xlock(c4172b54,0,c0ae9120,c9,c4172b54,...) at _sx_xlock+0x7d
devfs_allocv(c415db80,c4174000,e2888c28,c3e1ecc0,c0afe288,...) at
devfs_allocv+0x144
devfs_root(c4174000,2,c0c67378,c3e1ecc0,ca,...) at devfs_root+0x51
set_rootvnode(c0c67360,0,c0afe288,5f4,c07e4aa0,...) at set_rootvnode+0x2b
vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x356
start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65
fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 ---
Trying to mount root from ufs:/dev/ad4s1a
lock order reversal:
1st 0xc40939e8 ufs (ufs) @
/mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
2nd 0xc4174000 vfslock (vfslock) @
/mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:364
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e28889d8,c07a70de,c0af8353,c4174000,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c4174000,c0afe39a,c0afe39a,c0afe937,...) at
kdb_backtrace+0x29
witness_checkorder(c4174000,1,c0afe937,16c,e2888a18,...) at
witness_checkorder+0x6de
_lockmgr_args(c4174000,20001,c4174030,0,ffffffff,...) at
_lockmgr_args+0x1d5
vfs_busy(c4174000,0,0,c3e1ecc0,e2888b58,...) at vfs_busy+0x1b0
lookup(e2888b44,c0afe022,c6,bf,c3dee22c,...) at lookup+0x7bf
namei(e2888b44,c4174030,1c1,c0afe288,e2888b54,...) at namei+0x34b
kern_unlink(c3e1ecc0,c0afe6d9,1,62f,0,...) at kern_unlink+0x40
vfs_mountroot_try(c0afe893,c0aec557,c0ae4ade,1,c07e4aa0,...) at
vfs_mountroot_try+0x470
vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x418
start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65
fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 ---
lock order reversal:
1st 0xc3e22044 user map (user map) @
/mnt/wdx/freebsd/8.0/usr/src/sys/vm/vm_map.c:3111
2nd 0xc40937c8 ufs (ufs) @
/mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e28889c4,c07a70de,c0af8353,c40937c8,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c40937c8,c0aece96,c0aece96,c0afe937,...) at
kdb_backtrace+0x29
witness_checkorder(c40937c8,1,c0afe937,810,e28889e8,...) at
witness_checkorder+0x6de
_lockmgr_args(c40937c8,30041,c40937f8,0,ffffffff,...) at
_lockmgr_args+0x1d5
ffs_lock(e2888a78,c075fc3d,c0c20554,30041,c4093770,...) at ffs_lock+0xa3
VOP_LOCK1_APV(c0bcbec0,e2888a78,c0aec555,3,c40937f8,...) at
VOP_LOCK1_APV+0xa5
_vn_lock(c4093770,30041,c0afe937,810,0,...) at _vn_lock+0xf7
vget(c4093770,30041,c3e1ecc0,4a9,c1460600,...) at vget+0x10b
vnode_pager_lock(c1460480,0,c0b157d5,127,e2888be8,...) at
vnode_pager_lock+0x1ad
vm_fault(c3e22000,80cf000,2,8,80cf340,...) at vm_fault+0x1df
trap_pfault(5,0,c0b23bd2,2c4,c3e1ccd0,...) at trap_pfault+0x118
trap(e2888d38) at trap+0x259
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---

I'm gettig both of these as well. It doesn't stop the system
from booting, or _seem_ to affect operation ... but it would be nice
if they would go away.



Robert Huff
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"