On Fri, Mar 17, 2006 at 06:51:42PM +0800, Ariff Abdullah wrote: > I think I've read somewhere about panic during early root mount, fsck > etc.. Perhaps this might be related: > > Full dmesg: http://people.freebsd.org/~ariff/misc/dmesg.boot.amd64 > > [....] > acquiring duplicate lock of same type: "vnode interlock" > 1st vnode interlock @ kern/vfs_vnops.c:791 > 2nd vnode interlock @ kern/vfs_subr.c:2018 > KDB: stack backtrace: > witness_checkorder() at witness_checkorder+0x4da > _mtx_lock_flags() at _mtx_lock_flags+0x4a > vrefcnt() at vrefcnt+0x31 > null_checkvp() at null_checkvp+0x65 > null_lock() at null_lock+0x5b > VOP_LOCK_APV() at VOP_LOCK_APV+0x81 > vn_lock() at vn_lock+0x6b > nullfs_root() at nullfs_root+0x4c > vfs_donmount() at vfs_donmount+0x1096 > nmount() at nmount+0x82 > syscall() at syscall+0x21b > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x800679e8c, rsp = > 0x7fffffffe558, rbp = 0x7fffffffee40 ---
It does not seem to be the moment of mounting root. Do you have
nullfs mounts in fstab ? If yes, then, probably, some user-mode
output is absent in your trace.
Anyway, issue looks like cosmetic
and manifests itself only under both WITNESS and DIAGNOSTIC options,
living itself in diagonstic code.
The patch shuts the witness in dirty manner:
Index: sys/fs/nullfs/null_subr.c
===================================================================
RCS file: /usr/local/arch/ncvs/src/sys/fs/nullfs/null_subr.c,v
retrieving revision 1.50
diff -u -r1.50 null_subr.c
--- sys/fs/nullfs/null_subr.c 22 Feb 2006 06:15:12 -0000 1.50
+++ sys/fs/nullfs/null_subr.c 17 Mar 2006 12:13:46 -0000
@@ -306,7 +306,7 @@
while (null_checkvp_barrier) /*WAIT*/ ;
panic("null_checkvp");
}
- if (vrefcnt(a->null_lowervp) < 1) {
+ if (a->null_lowervp->v_usecount < 1) {
int i; u_long *p;
printf("vp = %p, unref'ed lowervp\n", (void *)vp);
for (p = (u_long *) a, i = 0; i < 8; i++)
I do not think that it worthy to reorg code to allow
to use vrefcnt.
pgphQCXUAOE9C.pgp
Description: PGP signature
