Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Sep 1997 20:23:59 +0200 (MET DST)
From:      Christoph Weber-Fahr <wefa@unicom.talkline.de>
To:        FreeBSD-gnats-submit@FreeBSD.ORG
Subject:   kern/4508: nfs3 data integrity problems
Message-ID:  <199709101823.UAA04192@helena.unicom.de>
Resent-Message-ID: <199709101830.LAA18239@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         4508
>Category:       kern
>Synopsis:       nfs3 data integrity problems
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 10 11:30:01 PDT 1997
>Last-Modified:
>Originator:     Christoph Weber-Fahr
>Organization:
O.tel.o Communications
>Release:        FreeBSD 2.2.2-RELEASE i386
>Environment:

	two FreeBSD 2.2.2-RELEASE machines.
	- P90/32MB/3C590/AHA2940
	- 486DX2-66i/16MB/NE2000 Clone/AHA1542B

>Description:

	Machine 2 acts as "code server", i.e. it has the complete source
 	tree and nfs-exports it to various other machines, among them #1.
	Machine 1 tries to compile a kernel for a third machine.
	in 90% of the attempts compilation falls over various
        errors in vnode_if.c . vnode_if.c is generated by a shell script
 	in the make depend step. When examining vnode_if.c one notices
	a large block of zero bytes (0x00) within the file.
	Every Test involved at least a complete "make clean;make depend;make"
	cycle.
	The problem goes away, when
	- one removes vnode_if.c and restarts make (it is newly generated
	  by the make process)
	- one compiles the kernel locally on machine 2 (doing the make depend
	  step there is sufficient)
	- one forces nfs2 mount between the machines.

	The abovementioned problem is the most often boserved one.
	I also got sucessful compiles and unexplainable link fails and
	similar effects.

	My suspicion is that in certain stress situations nfs writes 
	are not correctly transmitted. The problem occurs with both TCP
	and UDP mounts so I tend not to blame underlying protocols.
	

>How-To-Repeat:

	use the abovementioned (or similar) system combo.
	mount /usr/src from system 2 on /usr/src on system 1
	Generate a kernel according to the appended kernel file
	on system 1 in the nfs-mounted kernel compile directory.
	
#
# REM: minimal kernel for a small simple 386sx machine with 5 Megs
#

machine		"i386"
cpu		"I386_CPU"
ident		REM
maxusers	5

options		GPL_MATH_EMULATE
options		INET
options		FFS
options		PROCFS
options		"COMPAT_43"
options		FAILSAFE

config		kernel	root on wd0

controller	isa0

controller	wdc0	at isa? port "IO_WD1" bio irq 14 vector wdintr
disk		wd0	at wdc0 drive 0

device		sc0	at isa? port "IO_KBD" tty irq 1 vector scintr

device		npx0	at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr

device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr

device		lpt0	at isa? port? tty irq 7 vector lptintr

device ep0 at isa? port 0x300 net irq 10 vector epintr

pseudo-device	loop
pseudo-device	ether
pseudo-device	log
pseudo-device	tun	1
pseudo-device	pty	8


>Fix:

	none.
	Workaround: use nfs2
	

>Audit-Trail:
>Unformatted:



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