Subject: kern/17724: panic when using null mount
To: None <>
From: None <>
List: netbsd-bugs
Date: 07/26/2002 00:06:44
>Number:         17724
>Category:       kern
>Synopsis:       panic when using null mount
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 25 15:09:00 PDT 2002
>Originator:     Krister Walfridsson
>Release:        NetBSD 1.6_BETA4 (NetBSD-daily/200207240000)
System: NetBSD pc 1.6_BETA4 NetBSD 1.6_BETA4 (GENERIC) #0: Wed Jul 24 22:39:17 UTC 2002 i386
Architecture: i386
Machine: i386

I can repeatedly panic the the kernel by doing a gcc "make bootstrap" in
a null mounted directory.

I don't have a swap partition on this computer, so I cannot provide a
core dump, but the trace looks like:

uvm_fault(0xe3433818, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped in pid 15251 (filebuf_members.) at      fifo_write+0x12:        movl   0
db> trace
fifo_write(e3b0be4c,20000,0,c02b4bdf,30002) at fifo_write+0x12
ufsfifo_write(e3b0be4c,e37f2dcc,0,0,e37f2dcc) at ufsfifo_write+0x2a
layer_bypass(e3b0be4c,30002,0,0,1) at layer_bypass+0xd7
VOP_WRITE(e37f2dcc,e3b0bee0,1,c1119080,e3b0bf80) at VOP_WRITE+0x3b
vn_write(e3256ed4,e3256efc,e3b0bee0,c1119080,1) at vn_write+0x9f
dofilewrite(e3af03ac,4,e3256ed4,804f000,1) at dofilewrite+0x9b
sys_write(e3af03ac,e3b0bf80,e3b0bf78,c037682c) at sys_write+0x46
syscall_plain(1f,1f,1f,1f,804f000) at syscall_plain+0xa7

I have the following mount points (please don't ask why they are set up as
they are...):

   /dev/wd0a on / type ffs (local) on /dsk2 type nfs
   /usr/local/exports/gcctests/i386 on /gcctmp type null (local)
   /usr/local/exports/diskless on /diskless type null (NFS exported, local)
   /usr/local/exports/gcctests on /gcctests type null (NFS exported, local)

The panic happens (at the same time each time i try) when doing 'make check'
in the libstdc++-v3 within the /gcctmp mount point. It is however not enough
to just do a 'make check' to reproduce this problem -- it seems to require
the full bootstrap process. (btw. in case someone want to try to reproduce
this bug: it is not reproduceable by building just any gcc tarball. I get
this problem when building gcc source from July 23 and July 24, but not
July 17 for example...)