The following reply was made to PR kern/28952; it has been noted by GNATS.

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/28952
Date: Thu, 24 Feb 2005 09:32:59 -0500

 Just a routine update:
 
 It appears that this crash did not occur anymore, and the only apparent
 difference seems that the filesystem is not as full as it was.  After
 moving some of the projects to another system, although still running
 the same software, we are getting decent uptimes again on the same box,
 and no kernel/OS changes were made.
 
 Now noticing this, the system uses a single large FFS2 filesystem,
 consisting of /, apart from the ones mounted via NFS (and not using the
 unstable NQNFS extensions anymore since quite a while, this crash was
 experienced with it turned off back then as well).  At occasions our
 filesystem now reaches a 90% barrier imposed by quotas and no crash
 occurred still.  Back then, we used to often reach 99%, and occasionally
 dmesg did show applications not being able to write to the HD anymore,
 when obviously reaching the unprivileged user limits).
 
 This may very well be related.  Another point is that although our
 applications that were tested on that box were usually threaded, we do
 run those same ones on production on a server running the same release,
 compiled with same optimization flags for the same CPU, and we never
 experienced this problem on those servers.  They obviously do not fill /
 and are using various filesystems for /, /usr/, /var/, /usr/local/,
 /tmp/ and /home.  None of the filesystems ever get filled over 60%
 either, and they're been running rock-stable.  However, they also don't
 run X11, while that test box which used to crash does (using a Rage128 AGP
 16MB card with 2D accelerated features enabled).
 
 Thanks, Matt