On Tue, 16 Apr 1996 12:49:30 -0400 (EDT), "Andrew E. Mileski"
<aem@nic.ott.hookup.net> said:
>> > > What I found out was that if I told the kernel I had 384 KB less
>> > > than what I really had, the system would boot with nearly all of the
>> > > available 32 MB of memory, and the external cache as well.
This is not good behaviour...
> 32M-384k is _NORMAL_ and the point I was trying to make.
Yes. Linux already knows this and takes it into account.
> The 384k is reserved by the motherboard, and is damned near
> impossible to access (it varies from board to board).
> It is used for stuff like caching the BIOS and VGA ROMs
> so that it doesn't go completely to waste. If you disable
> caching you _still_ don't get the memory back either.
Absolutely. That's why the hardware behaviour you're defending is
actually broken.
If you say mem=32m to linux, it will use all memory from 4K to 768K,
then from 1024K to 32MB, omitting the 384K hole at <1024K
automatically.
The problem being discussed was that the motherboard wouldn't work
unless you specified mem=(32MB-384K), which simply tells linux to
ignore the last 384K of memory at the 32MB boundary. This is quite
clearly a motherboard problem, not a Linux one. Linux is already
handling the memory hole at <1024K; the motherboard has got no
business creating _another_ hole at <32MB.
In this particular case, since the problem is related to the external
cache, it's hard to see how Linux can reliably detect the problem. It
looks as if the memory is really there, but is just not being dealt
with by the motherboard l2 cache logic.
Cheers,
Stephen.
-- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.