From owner-freebsd-current@FreeBSD.ORG Wed May 14 00:26:47 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9359237B401; Wed, 14 May 2003 00:26:47 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96BE243FBD; Wed, 14 May 2003 00:26:46 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0019.cvx21-bradley.dialup.earthlink.net ([209.179.192.19] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Fqew-0000Hh-00; Wed, 14 May 2003 00:26:43 -0700 Message-ID: <3EC1EEB0.33B3132A@mindspring.com> Date: Wed, 14 May 2003 00:22:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan =?iso-8859-1?Q?E=DFer?= References: <20030513215348.K14785@daneel.foundation.hs> <3EC1CBC8.E263A9EF@mindspring.com> <20030514070823.GA71857@StefanEsser.FreeBSD.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a416ff0487c2356890218f5ae43e52e74a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Robert Watson cc: re@freebsd.org cc: Heiko Schaefer cc: current@freebsd.org Subject: Re: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2003 07:26:48 -0000 Stefan E=DFer wrote: > On 2003-05-13 21:53 -0700, Terry Lambert wro= te: > > > wouldn't a release that corrupts data in many, relevant, cases (i c= onsider > > > the box i had the trouble with entirely mainstream) be worse than n= o > > > release at all? > > > > Bosko's fix raises the minimum memory requirements by 3M. It's > > probably worth it for most people, but it will probably annoy > > other people... > = > Seems we could have DISABLE_PG_G in GENERIC and have Bosko's fix > compiled in for CPU models >=3D 586 (the 486 isn't affected, AFAIK) > only if DISABLE_PG_G is NOT specified in the kernel config file ? > = > I.e. GENERIC disables use of 4M pages but does not need the extra > 3MB of RAM, while a custom kernel without DISABLE_PG_G needs the > extra memory but contains the "fix" ... The base memory address at which the kernel is linked is not that mutable. It has to be done at compile time, not runtime. Maybe something could be done with the load vs. the relocation address in the loader, with the cooperation of locore.s; it'd be more work. I'd prefer it if more people tried Bosko's fix, first, before making plans like this, though. -- Terry