From owner-freebsd-current  Mon Mar 30 02:20:50 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id CAA08607
          for freebsd-current-outgoing; Mon, 30 Mar 1998 02:20:50 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA08600
          for <current@FreeBSD.ORG>; Mon, 30 Mar 1998 02:20:47 -0800 (PST)
          (envelope-from luoqi@watermarkgroup.com)
Received: by watermarkgroup.com (4.1/SMI-4.1)
	id AA16817; Mon, 30 Mar 98 05:20:06 EST
Date: Mon, 30 Mar 98 05:20:06 EST
From: luoqi@watermarkgroup.com (Luoqi Chen)
Message-Id: <9803301020.AA16817@watermarkgroup.com>
To: rb@gid.co.uk, toor@dyson.iquest.net
Subject: Re: panic: "vm_fault: fault on nofault entry" with softupdates
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > Hi,
> > 
> > I'm getting occasional "vm_fault: fault on nofault entry" panics running
> > with softupdates on a recent kernel (CTM src-cur 3301). The traceback looks
> > like this:
> > 
> > panic
> > vm_fault
> > trap(10,...
> > --- trap 0xc, ...
> > generic_bcopy
> > softdep_setup_allocindir_page
> > ffs_balloc
> > ffs_write
> > vn_write
> > write
> > [syscall stuff]
> > 
> > There seems to be no particular rhyme of reason to this, it happens every
> > third or fourth buildworld. Any ideas?
> > 
> That specific bug is a nit leftover from the softupdates port.  Will
> eventually be fixed.  I did look at it today, and fixed one bug, but
> it seems that there are more to be found.
> 
This bug seems to be caused by a missing VOP_BMAP call for the indirect
block. The code allocates a block device buf at b_blkno, which is still
a negative number and eventually leads to panic in bcopy.

Please try the following patch -- I am not sure if this is the correct
way to fix this problem. The real problem is that bufs returned by
bread() are no longer guaranteed to be bmapped after the VMIO merge
(bmap calls are moved to bdwrite), yet Kirk's code still makes that
assumption.

-lq

--- ffs_softdep.c	Fri Mar 20 11:22:14 1998
+++ ffs_softdep.c.orig	Mon Mar 30 04:55:56 1998
@@ -1528,14 +1528,6 @@
 		newindirdep->ir_state = ATTACHED;
 		LIST_INIT(&newindirdep->ir_deplisthd);
 		LIST_INIT(&newindirdep->ir_donehd);
-		if (bp->b_blkno == bp->b_lblkno) {
-#ifdef DEBUG
-			printf("setup_allocindir_phase2: need bmap, blk %d\n",
-				bp->b_lblkno);
-#endif
-			VOP_BMAP(bp->b_vp, bp->b_lblkno, NULL, &bp->b_blkno,
-				NULL, NULL);
-		}
 		newindirdep->ir_saveddata = (ufs_daddr_t *)bp->b_data;
 		newindirdep->ir_savebp =
 		    getblk(ip->i_devvp, bp->b_blkno, bp->b_bcount, 0, 0);

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message