Date: Tue, 1 Jun 1999 11:46:48 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: sheldonh@uunet.co.za (Sheldon Hearn) Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 machdep.c Message-ID: <19990601184648.A43DD14FA8@hub.freebsd.org> In-Reply-To: <49669.928261824@axl.noc.iafrica.com> from Sheldon Hearn at "Jun 1, 1999 8:30:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990601184648.A43DD14FA8>