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: