From owner-freebsd-hackers  Sun Mar  9 09:50:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA02485
          for hackers-outgoing; Sun, 9 Mar 1997 09:50:42 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02480
          for <freebsd-hackers@freefall.FreeBSD.org>; Sun, 9 Mar 1997 09:50:38 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA00483; Sun, 9 Mar 1997 12:50:06 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sun,  9 Mar 1997 12:50 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id GAA13988; Sun, 9 Mar 1997 06:32:26 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id GAA19040; Sun, 9 Mar 1997 06:38:17 -0500 (EST)
Date: Sun, 9 Mar 1997 06:38:17 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199703091138.GAA19040@lakes.water.net>
To: ponds!freefall.cdrom.com!freebsd-hackers, ponds!clinet.fi!hsu
Subject: Re: kern/2923: panic: vm_fault: fault on nofault entry, addr: f6e21000
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> This problem is exactly the same as bad dir panic, it just freaks out
> differently.  The panic always occurs at the above point, with wrong data
> (usually seems contents of a some file) in a block the directory lookup
> routine thinks is part of a directory.

 Yep - that's exactly my dup alloc and bad dir panic.

> 
> Access to this and 4-5 other dumps on the subject is available on request I
> do not have space for more than 4-5 dumps on-line.  They seem to always be
> from the same problem, so there should be good material to find
> similarities from to solve this.

 Well - not to discourage you; I've been looking for a year and haven't
found it :-)

> 
> >How-To-Repeat:
> 
> Run a news server with 2.2.  Full feed and bunch of readers (around 100
> max, but panics usually occur with less load).  Expire articles one-by-one
> to keep the free disk space at certain limit instead of running traditional
> expire.  The latter may contribute to the problem, as I got metoos for
> this.
> 
> This same problem happens with all machines, but the problem is very rare
> with unloaded machines.

 I believe it to be a timing problem in the kernel.  A heavy load just
gives you a greater opportunity (as a percentage of time) to trip over
the problem.  Again; this also happens on my extremely lightly loaded
(i.e. only a shell) system I put together just to reproduce this problem.

	- Dave Rivers -