From owner-cvs-all  Tue Jun  1 11:46:50 1999
Delivered-To: cvs-all@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id A43DD14FA8; Tue,  1 Jun 1999 11:46:48 -0700 (PDT)
Subject: Re: cvs commit: src/sys/i386/i386 machdep.c
In-Reply-To: <49669.928261824@axl.noc.iafrica.com> from Sheldon Hearn at "Jun 1, 1999  8:30:24 pm"
To: sheldonh@uunet.co.za (Sheldon Hearn)
Date: Tue, 1 Jun 1999 11:46:48 -0700 (PDT)
Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG,
	jlemon@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 861       
Message-Id: <19990601184648.A43DD14FA8@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

> 
> 
> On Tue, 01 Jun 1999 11:25:30 MST, Jonathan Lemon wrote:
> 
> >   Null commit; note that there is a new memory sizing routine that uses
> >   the BIOS calls to determine the memory configuration.  This should fix
> >   problems with >64M for good.
> 
> Does this mean MAXMEM can go away?

No.
 
There's another side to MAXMEM, which is that you can use it to explicitly
tell the kernel not to use all available memory on purpose. I use this
a lot when doing driver debugging because the machines I use for testing
have lots of RAM and crash dumps are always the same size as available RAM.
Capturing and analyzing a 128MB or 256MB crash dump can be a pain in the
neck sometimes. Typically, once I find a set of conditions that trigger
a panic, I'll set up a debug kernel that only uses 16MB of RAM and      
then capture a crash dump from that. 
 
-Bill


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message