Subject: kern/13361: Building -g kernels over NFS to an Alpha server can damage .rodata
To: None <gnats-bugs@gnats.netbsd.org>
From: None <nathanw@mit.edu>
List: netbsd-bugs
Date: 07/02/2001 19:31:54
>Number:         13361
>Category:       kern
>Synopsis:       Building kernels over NFS to an Alpha server occasionally inserts zeros
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 02 16:30:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Nathan J. Williams
>Release:        NetBSD-current 20010628
>Organization:
	Massachvsetts Institvte of Technology
>Environment:
	
System: NetBSD daffy-duck.putnam 1.5W NetBSD 1.5W (DAFFY-DUCK) #150: Thu Jun 28 01:45:50 EDT 2001 nathanw@daffy-duck.putnam:/u1/nbsd/src/sys/arch/alpha/compile/DAFFY-DUCK alpha
Architecture: alpha
Machine: alpha
>Description:

Set up a kernel source tree on an Alpha (pc164) running -current; NFS
export it (filesystem is using softdeps).

Mount the filesystem on a i386 box (Pentium 233) also running
-current. Configure and build a custom kernel with makeoptions=-g.

The kernel will fail to boot, ultimately because the start of the
.rodata section (load address range c02686c0-c0269000, file offsets
1696c0-16a000) is zeroed out, as displayed by "objdump -j .rodata -s
netbsd".

If the NFS options on the client are changed from "rw" to "rw,-w=4096"
or other smaller power-of-2 sizes for -w, the problem goes away. 8192
and larger powers of two (tested to 32k) still have the
problem. Changing the read size does not affect the problem. Using a
TCP mount does not affect the problem. 

The fact that good and bad kernels can be generated from the same set
of files places the blame at the link stage:

ld -Ttext c0100000 -e start -T ../../../../arch/i386/conf/kern.ldscript -X -o netbsd ${SYSTEM_OBJ} vers.o

	
>How-To-Repeat:

See above. However, the problem does not always surface. Sometimes it
doesn't happen, but when it does, it does so consistently. 

I have so far been unable to reproduce the problem with a 1.5 kernel
on the client, but due to the not-always-reproducable nature of the
problem, I can not be sure that it is not present.

Avaliable at http://hmsputnam.ne.mediaone.net/nathan/netbsd/ are the
following files for examination:

netbsd.good.gz: Working kernel built with -w=4096
netbsd.bad.gz:  Broken kernel built with -w=8192

builddump-bad-1.gz: tcpdump trace of a bad build (-w=8192)
builddump-bad-2.gz: tcpdump trace of another bad build (-w=8192)
builddump-good-1.gz: tcpdump trace of a good build (-w=4096)

Other information avaliable on request.

>Fix:

Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: