From owner-freebsd-hackers Sun Mar 14 10:20: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by hub.freebsd.org (Postfix) with ESMTP id A6EC614E7E for ; Sun, 14 Mar 1999 10:20:01 -0800 (PST) (envelope-from mtaylor@cybernet.com) Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by gateway.cybernet.com (8.8.8/8.8.8) with SMTP id NAA19407; Sun, 14 Mar 1999 13:19:05 -0500 (EST) (envelope-from mtaylor@cybernet.com) Date: Sun, 14 Mar 1999 13:19:05 -0500 (EST) From: "Mark J. Taylor" To: Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: Proposal: Define MAXMEM in GENERIC In-Reply-To: <35437.921428498@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It is trivial (we did it for 2.2.x) to add a boot option to always, or never, perform a speculative memory probe. For our NetMAX product (shameless plug: http://www.netmax.com/), which is 2.2.7+ based (we're working on a 3.1 version), we've added two additional boot options: 1) -M always perform speculative memory probe 2) -m never perform speculative memory probe We have one machine here that has 64 MB RAM that (used to) hang or reboot during the speculative probe. The "-m" option works great. We go in to either userconfig to modify the npx0 device to set the RAM size, or use our "kset" program to modify kernel devices, so we don't have to boot "-m" subsequently. Anyone interested in code? -Mark Taylor NetMAX Developer mtaylor@netmax.com On Sun, 14 Mar 1999, Sheldon Hearn wrote: > > Hi folks, > > The originator of PR i386/9755 (which related to a 3.0-RELEASE install > failure) has made a valid point. > > We know that some people with >64MB RAM are going to have trouble with > the speculative memory probe while installing FreeBSD with the GENERIC > (here read any release) kernel. So why don't we add to GENERIC the > following line? > > options "MAXMEM=(64*1024)" > > The major argument that comes to mind immediately is that people are > going to end up running sub-optimal servers out-of-the-box. However, the > change is supported by the following mindset: > > Gain: > Make things easier for people with broken hardware. > > Cost: > Annoy the people who have large memory configurations and who > don't build custom kernels. > > I'm of the opinion that we're talking about a number of annoyed people > so small that the gain is justified. > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message