[lkml]   [1996]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: memory detection and bios
On Tue, 22 Oct 1996, Jon Tombs wrote:

> said:
> >
> > bios can only report 64Meg. Is there a reason the kernel can't do
> > a search for the memory boundary if 64Meg is available? [e.g. check
> > at 128M, 256M, ... then binary search for boundary when get a miss --
> > maybe do something quick and simple to check for a proper boundary like
> > check the location immediately past the last known good location.]
> >
> > If this causes problems on some machines it could be made a config option.
> >
> > For people whose bioses report the wrong value, this could be made
> > "always on" instead of "only if 64M reported".
> What if you have a memory mapped device or frame buffer at 128MB. Memory probes
> can be quite dangerous with some hardware (the probe tells your
> memory mapped scsi controler to format the drive..)
> Just add mem=XXXM to the kernel boot options (e.g. append option in
> lilo.conf) and all will be well.

There are 4 ways Linux can find out how much memory there is avalable:

1. Ask the bios; this is what we do, and the bios tells there is n Kb
of memory, where n is a 16 bit number (ie 64Mb maximum).

2. Ask the bios in a newer way; we proberbly will do this in 2.1.x
(may already), this isn't limited to 64Mb, but it's not supported
by all bioses, and so may fail.

3. Ask the hardware (this is not probing); you can read it out of
some chip (sorry I forget which, tho I think it may be the clock
chip), it's the one the bios asks, and so it should work just
fine, at least some of the *BSD*'s do this.

4. Ask the admin (ie lilo tells us that we have xMb of memory),
always works, cannot fail, unless we are fed silly numbers

> Jon.
> --
> Jon. <,>

PGP key pass phrase forgotten, \ Overload -- core meltdown sequence
again :( and I don't care ;) | initiated.
/ This space is intentionally left
| blank, apart from this text ;-)

 \ /
  Last update: 2005-03-22 13:38    [W:0.040 / U:19.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site