I try to narrow it down. kernel from Jun 10 produces LOR (below) but works afterwards while kernel from Jun 16 hangs. lock order reversal: 1st 0xc68f7d18 ufs (ufs) _at_ kern/vfs_mount.c:1193 2nd 0xc6b83278 devfs (devfs) _at_ kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper(c0802170,ee7a68e4,c062fc09,c061f088,c0805aeb,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c061f088,c0805aeb,c64f1360,c64f1290,ee7a6940,...) at kdb_backtrace+0x29 _witness_debugger(c0805aeb,c6b83278,c07f1d57,c64f1290,c080cef5,...) at _witness_debugger+0x1e witness_checkorder(c6b83278,9,c080ceec,856,0,...) at witness_checkorder+0x81e __lockmgr_args(c6b83278,80100,c6b83298,0,0,0,c080ceec,856) at __lockmgr_args+0x7c6 vop_stdlock(ee7a6a5c,c062f9e5,c07f2080,80100,c6b83220,...) at vop_stdlock+0x5c VOP_LOCK1_APV(c0862d20,ee7a6a5c,c6bb6670,c0897740,c6b83220,...) at VOP_LOCK1_APV+0xaf _vn_lock(c6b83220,80100,c080ceec,856,8,...) at _vn_lock+0x5e vget(c6b83220,80100,c6bb65c0,196,c07f1f76,...) at vget+0xb8 devfs_allocv(c6b52080,c6b7d000,80000,ee7a6af4,ee7a6b40,...) at devfs_allocv+0xfe devfs_root(c6b7d000,80000,ee7a6ba4,c6bb65c0,ee7a6b24,...) at devfs_root+0x52 vflush(c6b7d000,1,0,c6bb65c0,0,...) at vflush+0x49 devfs_unmount(c6b7d000,8000000,c080c58b,4ee,80,...) at devfs_unmount+0x46 dounmount(c6b7d000,8000000,c6bb65c0,473,2,...) at dounmount+0x45d unmount(c6bb65c0,ee7a6cec,28167690,1,0,...) at unmount+0x2b6 syscallenter(c6bb65c0,ee7a6ce4,c07977b9,c08b0250,0,...) at syscallenter+0x23f syscall(ee7a6d28) at syscall+0x2e Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d89ff, esp = 0xbfbfe5dc, ebp = 0xbfbfe6a8 --- -- http://ache.vniz.net/Received on Sun Jun 19 2011 - 21:23:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC