From owner-freebsd-stable@FreeBSD.ORG  Tue Feb 24 12:31:07 2004
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BEC2B16A4CE
	for <freebsd-stable@freebsd.org>;
	Tue, 24 Feb 2004 12:31:07 -0800 (PST)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 33A4043D2D
	for <freebsd-stable@freebsd.org>;
	Tue, 24 Feb 2004 12:31:07 -0800 (PST)
	(envelope-from gnagelhout@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72)
	id <15P45RTZ>; Tue, 24 Feb 2004 15:31:06 -0500
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337021AB1DD@mail.sandvine.com>
From: Gerrit Nagelhout <gnagelhout@sandvine.com>
To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>
Date: Tue, 24 Feb 2004 15:31:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: >2GB Bugs still exist in FreeBSD 4.9 ?
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Production branch of FreeBSD source code
	<freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2004 20:31:07 -0000

I think this problem happens when the kernel_map runs out of memory.  The
actual crash happens because in vfs_subr.c around line 704, if zalloc
returns NULL, the bzero will cause that trap:

simple_unlock(&vnode_free_list_slock);
vp = (struct vnode *) zalloc(vnode_zone);
bzero((char *) vp, sizeof *vp);  ******************
simple_lock_init(&vp->v_interlock);
vp->v_dd = vp;
cache_purge(vp);
LIST_INIT(&vp->v_cache_src);
TAILQ_INIT(&vp->v_cache_dst);
numvnodes++;


The size of the kernel memory region can be configured, and is typically
around 1GB.  The more RAM is present in the system, the more of this will be
used up by various data structures that are tuned differently depending how
much RAM is present.  I think there are a few more places where running out
of kernel memory will cause similar problems.  Most of these places don't
seem trivial to fix, and the only solution I have come up with (so far) is
to tune the kernel differently to leave more memory available.

Gerrit