Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 May 2003 00:22:24 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Stefan =?iso-8859-1?Q?E=DFer?= <se@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: 5.1-RELEASE TODO
Message-ID:  <3EC1EEB0.33B3132A@mindspring.com>
References:  <Pine.NEB.3.96L.1030513145309.72145R-100000@fledge.watson.org> <20030513215348.K14785@daneel.foundation.hs> <3EC1CBC8.E263A9EF@mindspring.com> <20030514070823.GA71857@StefanEsser.FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Stefan E=DFer wrote:
> On 2003-05-13 21:53 -0700, Terry Lambert <tlambert2@mindspring.com> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC1EEB0.33B3132A>