From owner-freebsd-bugs Tue Jan 27 12:20:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00197 for freebsd-bugs-outgoing; Tue, 27 Jan 1998 12:20:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: (from gnats@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00184; Tue, 27 Jan 1998 12:20:02 -0800 (PST) (envelope-from gnats) Date: Tue, 27 Jan 1998 12:20:02 -0800 (PST) Message-Id: <199801272020.MAA00184@hub.freebsd.org> To: freebsd-bugs Cc: From: Ian Dowse Subject: Re: kern/3438: Use of NFS v3 might cause a trap 12 Reply-To: Ian Dowse Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/3438; it has been noted by GNATS. From: Ian Dowse To: freebsd-gnats-submit@freebsd.org, Tor.Egge@idi.ntnu.no Cc: Subject: Re: kern/3438: Use of NFS v3 might cause a trap 12 Date: Tue, 27 Jan 1998 20:10:19 +0000 Could somebody apply Tor's fix for this problem to the -stable tree too? Since moving about 1500 nfs-mounted user home directories to FreeBSD servers, resulting in NFS v3 being used by clients, we have been getting frequent client panics in reassignbuf() and nfs_flush(). The fault address is always around NOLIST (0x87654321) and the panics occur during NFS writes when the machine is fairly busy. The following patch to nfs/nfs_bio.c (as applied in rev 1.37 in -current) seems to fix the problem: --- nfs_bio.c.old Tue Jan 27 19:36:57 1998 +++ nfs_bio.c Tue Jan 27 19:37:34 1998 @@ -1059,7 +1059,7 @@ io.iov_base = (char *)bp->b_data + bp->b_dirtyoff; uiop->uio_rw = UIO_WRITE; nfsstats.write_bios++; - if ((bp->b_flags & (B_ASYNC | B_NEEDCOMMIT | B_NOCACHE)) == B_ASYNC) + if ((bp->b_flags & (B_ASYNC | B_NEEDCOMMIT | B_NOCACHE | B_CLUSTER)) == B_ASYNC) iomode = NFSV3WRITE_UNSTABLE; else iomode = NFSV3WRITE_FILESYNC; Ian