Date: Sun, 14 Mar 1999 13:19:05 -0500 (EST) From: "Mark J. Taylor" <mtaylor@cybernet.com> To: Sheldon Hearn <sheldonh@iafrica.com> Cc: hackers@FreeBSD.ORG Subject: Re: Proposal: Define MAXMEM in GENERIC Message-ID: <Pine.BSF.4.01.9903141246550.17166-100000@gateway.cybernet.com> In-Reply-To: <35437.921428498@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9903141246550.17166-100000>