lkml.org 
[lkml]   [1999]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: memory detection problems: 2.0.x vs. 2.2.x
Date
From

nathan.zook@amd.com wrote:

> I have scanned the code, and I have three questions and an observation.

OK. Hopefully I can answer your questions satisfactorily.


> First, in stage2/asm.c get_mmem_entry your comments indicate that you are
> loading es:di (which is as it should be), but your code appears to load
> si:di. Assuming the code is functioning, this is probably because es is
> preloaded with the correct value.

Further down, after the conversion to 16-bit mode, observe that
%si is moved into %es. It was a placeholder prior to the mode-switch.


> Second, I do not understand exactly how the bootloader is supposed to
> interface to the linux kernel. Historically, memory detection &
> initialization have been handled through such files as
> arch/i386/boot/setup.S, kernel/setup.c, and mm/init.c. While I understand
> that the boot loader may need the memory map in order to load the ram disk,
> I do not understand how the memory map is to be forwarded to the kernel.

Actually, it isn't right now. What *does* happen is that GRUB will
append a "mem=" option to the kernel command-line automatically with
the all the contiguous memory above 1MB. It walks the SMAP interface
and collects all the memory into one chunk for older kernel interfaces
such as Linux and the *BSDs.

It would be relatively easy to add the "multiboot" boot format to the
Linux kernel, which would forward the full memory map, but I've been
kinda lazy.


> Third, I have been advised that there are systems which die if e820 is
> called. Do you have #ifdefs or user options to diable this call on these
> systems?

Not right now. Clearly I could have missed something in the testing
that has been done, but it is used by a pretty large community of people
and I'm currently pretty sure there has been no hang reported related
to this.

I'd love to try it on said system if you have one handy. If nothing else,
it will give me a chance to figure out a workaround not based on #ifdef's,
as, for example, something related to this works fine on MS Windows.


> As for my observation, I'm not sure I agree with your bug checking. There
> are direct and indirect violations of the standard which can (and I think
> should) be checked which do not appear to be, such as es:di being left
> inviolate and e801 and 88 reports being consistent with the e820 report.

I'm not sure I follow this. There is some pretty careful checking to make
sure the SMAP interface returned actual data. It isn't used unless all
those values are correct. Plus, the MB is allowed to lie about it's memory
in the other interfaces if SMAP is supported. I've seen systems return
only 32MB, for example, if SMAP is there.

Besides, an accumulated total of memory over 1MB up to the first
chipset hole is always generated and passed to the kernel anyway, in case
it ignores the SMAP info. This is the value displayed in GRUB's bootup
screen.


> Also, while your reject of records of length >20 is certainly permitted
> under the spec, I have seen bios code which I fully expect will at some
> future date violate this part of the spec without otherwise giving invalid
> data. In order to future proof you code, I suggest that your code be able
> to accept such data, at the user's request.

The other possibility is to have it simply adaptively try to figure out
how much the BIOS will return, by trying it til the BIOS structures hit
a maximum size. And have some kind of sane "give up" size. Maybe add
an "advanced" feature where the user can specify the different probe
size, but NOT require it by default.

But in general, if the BIOS randomly walks over memory (which is what
this would be if I have specifically told it to return only 20 bytes),
this is very bad.


> In case you have not guessed, user control & future proofing are the fun
> parts of what I've been doing.

<chuckle> Sure.

--
Erich Stefan Boleyn \_ <erich@uruk.org>
Mad but Happy Scientist \__ http://www.uruk.org/
Motto: "I'll live forever or die trying" ---------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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