Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Dec 2003 11:24:29 -0800 (PST)
From:      Don Lewis <truckman@FreeBSD.org>
To:        shoesoft@gmx.net
Cc:        current@FreeBSD.org
Subject:   Re: 5.2-BETA panic: page fault
Message-ID:  <200312011924.hB1JOTeF026950@gw.catspoiler.org>
In-Reply-To: <1070238961.5827.17.camel@shoeserv.freebsd>

next in thread | previous in thread | raw e-mail | index | archive | help
On  1 Dec, Stefan Ehmann wrote:
> On Mon, 2003-12-01 at 01:10, Don Lewis wrote:
>> Can you reproduce this problem without bktr?
>> 
> <snip>
>> You are getting a double panic, with the second happening during the
>> file system sync.  The code seems to be be tripping over the same mount
>> list entry each time.  Maybe the mount list is getting corrupted.  Are
>> you using amd?  Print *lkp in the lockmgr() stack frame.
>> 
>> 
>> You might want to add
>> 	KASSERT(mp->mnt_lock.lk_interlock !=NULL, "vfs_busy: NULL mount
>>         pointer interlock");
>> at the top of vfs_busy() and right before the lockmgr() call.
> 
> No, I'm not using amd.
> 
> (kgdb) print *lkp
> $1 = {lk_interlock = 0x0, lk_flags = 0, lk_sharecount = 0, lk_waitcount
> = 0, 
>   lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, 
>   lk_lockholder = 0x0, lk_newlock = 0x0}
> 
> This is indeed just NULLs.
> 
> I haven't tried without bktr yet but I hope I'll have time for that (and
> the KASSERT) tomorrow.
> 
> The panic only seems to happen when accessing my read-only mounted ext2
> partition. Today I tried not to access any data there and uptime is
> 14h30min now. The panic always happened after a few hours. So this is
> probably the core of the problem.

What about ther file system types, like nullfs, unionfs, cd9660?  I
created an ext2 partition, filled it with data, and mounted it
read-only.  So far I am unable to reproduce this problem.

I'm also running with the DEBUG_VFS_LOCKS and the following patch in an
attempt to catch the bug closer to its origin.  Be forwarned that
DEBUG_VFS_LOCKS sometimes gets triggered by procfs and linprocfs, but
you can just continue in DDB.

Index: sys/kern/vfs_subr.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.472
diff -u -r1.472 vfs_subr.c
--- sys/kern/vfs_subr.c	9 Nov 2003 09:17:24 -0000	1.472
+++ sys/kern/vfs_subr.c	1 Dec 2003 13:34:23 -0000
@@ -282,6 +282,9 @@
 void
 assert_vop_locked(struct vnode *vp, const char *str)
 {
+	if (vp && vp->v_mount)
+		KASSERT(vp->v_mount->mnt_lock.lk_interlock != NULL,
+		    ("assert_vop_locked: vnode mount entry interlock is null"));
 	if (vp && !IGNORE_LOCK(vp) && !VOP_ISLOCKED(vp, NULL))
 		vfs_badlock("is not locked but should be", str, vp);
 }
@@ -289,6 +292,9 @@
 void
 assert_vop_unlocked(struct vnode *vp, const char *str)
 {
+	if (vp && vp->v_mount)
+		KASSERT(vp->v_mount->mnt_lock.lk_interlock != NULL,
+		    ("assert_vop_unlocked: vnode mount entry interlock is null"));
 	if (vp && !IGNORE_LOCK(vp) &&
 	    VOP_ISLOCKED(vp, curthread) == LK_EXCLUSIVE)
 		vfs_badlock("is locked but should not be", str, vp);





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312011924.hB1JOTeF026950>