From owner-freebsd-bugs Sun Nov 2 16:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20304 for bugs-outgoing; Sun, 2 Nov 1997 16:26:10 -0800 (PST) (envelope-from owner-freebsd-bugs) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20287; Sun, 2 Nov 1997 16:26:04 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id BAA01264; Mon, 3 Nov 1997 01:33:02 +0100 (CET) From: Mikael Karpberg Message-Id: <199711030033.BAA01264@ocean.campus.luth.se> Subject: Re: 2.2.5 installation bug on 1gig machines In-Reply-To: <199711010724.XAA28863@implode.root.com> from David Greenman at "Oct 31, 97 11:24:48 pm" To: dg@root.com Date: Mon, 3 Nov 1997 01:33:01 +0100 (CET) Cc: bugs@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to David Greenman: > >At 04:40 PM 10/31/97 -0800, David Greenman wrote: > >>You'll > >>have to physically pull out some of the memory and/or replace it with > >>lower density SIMMs until you've finished the installation and built a > >>customized kernel. > > > >Can the kernel know (or calculate) the maximum amount of memory it can > >use without crashing? If so, it could refuse to register memory greater > >than that amount. > > Uh, well, the answer to this is that there is a bug in the kernel that is > causing the problem. We didn't test kernel's with the BOUNCE_BUFFERS option > on any large memory systems. Otherwise, how much memory a system has is not > an issue with regard to the system crashing (resources allocated out of that > memory can be a problem if tuned wrong, but that is a different issue). I seem to remember some machines needing BOUNCE_BUFFERS at installation time so that the option must be there, but why not compile the installation boot disk's kernel with a small check that will simply "set" the memory to say, min(REAL_MEMORY, 32MB) so that it will never seem to have more then 32 MB memory during installation? That shouldn't matter that much during installation anyway, should it? /Mikael