Subject: Re: very weird NFS/VND error during "make depend" of kernel....
To: NetBSD-current Discussion List <>
From: Manuel Bouyer <>
List: current-users
Date: 06/27/2001 15:52:05
On Tue, Jun 26, 2001 at 07:56:54PM -0400, Greg A. Woods wrote:
> The weirdest thing just happened.  I've been running a "make release" on
> a sparc, with the sources on an i386 server, both running NetBSD of
> course (and in fact 2001/06/19 -current).  Suddenly in the middle of the
> 'mkdep' for the last kernel of the sparc build it spit up:
> 	cpp: /proven/work/woods/NetBSD-src/sys/sys/types.h: Input/output error
> 	cpp: machine/bswap.h: Input/output error
> 	cpp: /proven/work/woods/NetBSD-src/sys/arch/sparc/sparc/vm_machdep.c: Permission denied
> 	cpp: /proven/work/woods/NetBSD-src/sys/arch/sparc/sparc/disksubr.c: Permission denied
> 	cpp: /proven/work/woods/NetBSD-src/sys/arch/sparc/dev/md_root.c: Permission denied
> 	cpp: /proven/work/woods/NetBSD-src/sys/sys/param.h: Input/output error
> 	mkdep: compile failed.
> 	*** Error code 1
> 	Stop.
> 	make: stopped in /build/NetBSD-obj/arch/sparc/compile/INSTALL
> 	*** Error code 1
> This is after successfully building the GENERIC, GENERIC_SCSI3, and
> GENERIC_SUN4U kernels!  Note the "make release" was running as root too.
> Curiously it happened at almost exactly the same time I was doing a
> "make release" on the sources server and as it was starting to build the
> floppy images.
> The timestamps on these log entries correspond almost exactly to the
> timestamp on my prompt after the make on the sparc died:
> 	Jun 26 19:18:44 proven /netbsd: vnd0: no disk label
> 	Jun 26 19:18:45 proven last message repeated 2 times
> and the server had just finished building the ramdisk-big.fs image when
> I noticed the sparc build had died.
> There are no other related log entries on either machine.
> All of the files mentioned above are now readable without problem on the
> sparc.
> Is it possible that the vnd device is somehow having adverse affects on
> the NFS server?

It's not the vnd device, it's mount. when you mount/umount a filesystem,
mount will wake up mountd to rebuild the export list. mountd will flush the
current export list before installing the new one, so there is a short window
in which nothing is exported. Bad luck, you client tried talking to the
server at this time.

The bug is in the NFS system: NFS requests should either be dropped or
queued while mountd is working.

> Should I send-pr this?

I already have a PR open on this issue: 5844.
I just shaw it's closed, I open it again.
The fix which was commited has been backed out.

Manuel Bouyer, LIP6, Universite Paris VI.