Hi, I found some LOR looking at my dmesg. the system: a Sony s5 laptop (intel 770 at 2 ghz); 1G ram running current dated from: 2008 April 2. If these LOR are well known, please simply forget this message. lock order reversal: 1st 0xc496ce08 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2045 2nd 0xc4ad0614 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 KDB: stack backtrace: db_trace_self_wrapper(c0b0fe6d,e2f95bbc,c07add7e,c0b1235f,c4ad0614,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b1235f,c4ad0614,c0b03801,c0b03801,c0b03842,...) at kdb_backtrace+0x29 witness_checkorder(c4ad0614,9,c0b03842,c9,c7,...) at witness_checkorder+0x6de _sx_xlock(c4ad0614,0,c0b03842,c9,c4ad0614,...) at _sx_xlock+0x7d devfs_allocv(c4b0ec00,c4b26000,e2f95c28,c4627cc0,c0b180c1,...) at devfs_allocv+0x144 devfs_root(c4b26000,2,c0c83018,c4627cc0,ca,...) at devfs_root+0x51 set_rootvnode(c0c83000,0,c0b180c1,5f5,c07eb350,...) at set_rootvnode+0x2b vfs_mountroot(c0c30730,4,c0b07c9a,264,ffd7ff9d,...) at vfs_mountroot+0x356 start_init(0,e2f95d38,c0b0960f,30d,c4625cf8,...) at start_init+0x65 fork_exit(c073b5f0,0,e2f95d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2f95d70, ebp = 0 --- Trying to mount root from ufs:/dev/ad4s4a lock order reversal: 1st 0xc496c978 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2045 2nd 0xc4b26000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0b0fe6d,e2f959b4,c07add7e,c0b1235f,c4b26000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b1235f,c4b26000,c0b181bf,c0b181bf,c0b1875c,...) at kdb_backtrace+0x29 witness_checkorder(c4b26000,1,c0b1875c,16c,e2f959f4,...) at witness_checkorder+0x6de _lockmgr_args(c4b26000,20001,c4b26030,0,ffffffff,...) at _lockmgr_args+0x1d5 vfs_busy(c4b26000,0,0,c4627cc0,e2f95b3c,...) at vfs_busy+0x1b0 lookup(e2f95b24,c0b17e6f,d8,c0,c461132c,...) at lookup+0x7bf namei(e2f95b24,e2f95b28,c07ad55c,e2f95b30,c0c828a8,...) at namei+0x44b kern_unlinkat(c4627cc0,ffffff9c,c0b184fe,1,e2f95c5c,...) at kern_unlinkat+0x46 kern_unlink(c4627cc0,c0b184fe,1,630,0,...) at kern_unlink+0x27 vfs_mountroot_try(c0b186b8,c0b069cb,c0aff32c,1,c07eb350,...) at vfs_mountroot_try+0x476 vfs_mountroot(c0c30730,4,c0b07c9a,264,ffd7ff9d,...) at vfs_mountroot+0x418 start_init(0,e2f95d38,c0b0960f,30d,c4625cf8,...) at start_init+0x65 fork_exit(c073b5f0,0,e2f95d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2f95d70, ebp = 0 --- start_init: trying /sbin/init lock order reversal: 1st 0xc462b044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111 2nd 0xc496c730 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2045 KDB: stack backtrace: db_trace_self_wrapper(c0b0fe6d,e2f959e0,c07add7e,c0b1235f,c496c730,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b1235f,c496c730,c0b0727e,c0b0727e,c0b1875c,...) at kdb_backtrace+0x29 witness_checkorder(c496c730,1,c0b1875c,7fd,c0b307d9,...) at witness_checkorder+0x6de _lockmgr_args(c496c730,30041,c496c760,0,ffffffff,...) at _lockmgr_args+0x1d5 ffs_lock(e2f95a88,c0b32281,c0b069c9,30041,c496c6d8,...) at ffs_lock+0x72 VOP_LOCK1_APV(c0be6ba0,e2f95a88,c0bff060,c496c6d8,30041,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c496c6d8,30041,c0b1875c,7fd,c0b0bba3,...) at _vn_lock+0x5b vget(c496c6d8,30041,c4627cc0,4a9,c1c5f180,...) at vget+0xa1 vnode_pager_lock(c1c5f200,0,c0b2f8d7,127,e2f95be8,...) at vnode_pager_lock+0x1ad vm_fault(c462b000,80d3000,2,8,80d3000,...) at vm_fault+0x1df trap_pfault(5,0,c0b3e3ed,2c4,c4625cf8,...) at trap_pfault+0x118 trap(e2f95d38) at trap+0x259 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() lock order reversal: 1st 0xc4ba7978 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:2045 2nd 0xc4b25a70 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0b0fe6d,e6ee3a14,c07add7e,c0b1235f,c4b25a70,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b1235f,c4b25a70,c0b181bf,c0b181bf,c0b1875c,...) at kdb_backtrace+0x29 witness_checkorder(c4b25a70,1,c0b1875c,16c,e6ee3a54,...) at witness_checkorder+0x6de _lockmgr_args(c4b25a70,20001,c4b25aa0,0,ffffffff,...) at _lockmgr_args+0x1d5 vfs_busy(c4b25a70,10,0,c4b74aa0,0,...) at vfs_busy+0x1b0 vfs_donmount(810e080,c,e6ee3c70,c4c1f180,810b530,...) at vfs_donmount+0xdbc nmount(c4b74aa0,e6ee3cfc,c,c0b12fc9,c0bc7630,...) at nmount+0xb2 syscall(e6ee3d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280d727b, esp = 0xbfbfe96c, ebp = 0xbfbfedb8 --- best regards raoul rmgls@free.fr How-To-Repeat: simply booting the machine, all the time.
Responsible Changed From-To: freebsd-i386->freebsd-bugs This does not sound i386-specific.
Most of these LORs are known, but the 2nd and 4th LORs look interesting (I don't remember seeing LORs with vfslock and pseudofs recently). Reassigning to -fs@ for triage.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
The report is just too old.