From nobody  Tue Aug 12 21:00:05 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA18118;
          Tue, 12 Aug 1997 21:00:05 -0700 (PDT)
Message-Id: <199708130400.VAA18118@hub.freebsd.org>
Date: Tue, 12 Aug 1997 21:00:05 -0700 (PDT)
From: hfir@math.rochester.edu
To: freebsd-gnats-submit@freebsd.org
Subject: kernel panic: vm_fault: fault on nofault entry
X-Send-Pr-Version: www-1.0

>Number:         4289
>Category:       kern
>Synopsis:       kernel panic: vm_fault: fault on nofault entry
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 12 21:10:01 PDT 1997
>Closed-Date:    Mon Mar 29 15:57:17 PST 1999
>Last-Modified:  Mon Mar 29 15:58:17 PST 1999
>Originator:     Hoss Firooznia
>Release:        2.2.2-R
>Organization:
Department of Mathematics, University of Rochester
>Environment:
FreeBSD foo.math.rochester.edu 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: 
Tue Aug 12 23:08:56 EDT 1997 hfir@foo.math.rochester.edu:
/usr/src/sys/compile/FOO i386      
>Description:
kernel panics during use of "latex2html" when output directory is set 
to an NFS-mounted filesystem.  Output to local directories doesn't seem 
to cause the problem.  Unfortunately I'm not familiar with kernel
debugging, but based on instructions in the documentation I was able
to generate the following with 'gdb -k':

# gdb -k /var/crash/kernel.3 /var/crash/vmcore.3
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 20a000
current pcb at 1ee634
panic: vm_fault: fault on nofault entry, addr: %lx
#0  boot (howto=256) at ../../kern/kern_shutdown.c:243
243                                     dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:243
#1  0xf010dee2 in panic (
    fmt=0xf019af80 "vm_fault: fault on nofault entry, addr: %lx")
    at ../../kern/kern_shutdown.c:367
#2  0xf019b0aa in vm_fault (map=0xf05c1e80, vaddr=4074278912,
    fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:201
#3  0xf01b04c4 in trap_pfault (frame=0xefbffce0, usermode=0)
    at ../../i386/i386/trap.c:642
#4  0xf01b01ef in trap (frame={tf_es = -259391472, tf_ds = -220725232,
      tf_edi = 4844036, tf_esi = -220688384, tf_ebp = -272630452,
      tf_isp = -272630520, tf_ebx = 4096, tf_edx = -220690944, tf_ecx = 384,
      tf_eax = 4845572, tf_trapno = 12, tf_err = 0, tf_eip = -266669435,
      tf_cs = 8, tf_eflags = 66054, tf_esp = 4096, tf_ss = -272629960})
    at ../../i386/i386/trap.c:311
#5  0xf01af285 in generic_copyout ()
#6  0xf014a57a in nfs_bioread (vp=0xf08a1d00, uio=0xefbfff38, ioflag=0,
    cred=0xf088e980) at ../../nfs/nfs_bio.c:390
#7  0xf0179082 in nfs_readdir (ap=0xefbfff08) at ../../nfs/nfs_vnops.c:2072
#8  0xf01309ae in getdirentries (p=0xf07bc600, uap=0xefbfff94,
    retval=0xefbfff84) at vnode_if.h:639
#9  0xf01b0c63 in syscall (frame={tf_es = -272695257, tf_ds = -272695257,
      tf_edi = 1745656, tf_esi = 4916900, tf_ebp = -272640308,
      tf_isp = -272629788, tf_ebx = 135155808, tf_edx = 1745632, tf_ecx = 252,
      tf_eax = 196, tf_trapno = 7, tf_err = 7, tf_eip = 134969301, tf_cs = 31,
      tf_eflags = 582, tf_esp = -272640340, tf_ss = 39})
    at ../../i386/i386/trap.c:890
#10 0x80b77d5 in ?? ()
#11 0x4602a in ?? ()
#12 0x28202 in ?? ()
#13 0x26c4 in ?? ()
#14 0x1687 in ?? ()
#15 0x10d3 in ?? ()
(kgdb)      


>How-To-Repeat:
My guess is that the problem occurs when latex2html is calling its
companion script, "pstoimg", which in turn invokes a horrific pipeline
of image conversion programs, including dvips, gs, ppmtogif.  The 
files these programs manipulate can be quite large, so perhaps any
vigorous reading, writing, and directory creation/destruction on a
mounted directory will cause a repeat of the problem -- though I 
haven't noticed any problems of this sort before.
>Fix:

>Release-Note:
>Audit-Trail:

From: jason@ampersand.com (Jason Brazile)
To: freebsd-gnats-submit@freebsd.org, hfir@math.rochester.edu
Cc:  Subject: Re: kern/4289: kernel panic: vm_fault: fault on nofault entry
Date: Sun, 17 Aug 1997 14:10:31 -0400

 Sounds familiar. See kern/4200. Glad you were able to try it with 2.2.2 and
 give a gdb backtrace.
 
 I don't know if it matters but for the record I am using this version of 
 perl:
 
 	This is perl, version 5.003 with EMBED
 		built under freebsd at Mar 13 1997 00:09:56
 		+ suidperl security patch
 
 Jason
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Mon Mar 29 15:57:17 PST 1999 
State-Changed-Why:  
Active development on NFS for 2.2 is over. 
>Unformatted:
