lkml.org 
[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: memory detection problems: 2.0.x vs. 2.2.x
Date
I have scanned the code, and I have three questions and an observation.

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.

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.

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?

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.

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.


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

Nathan



-----Original Message-----
From: Erich Boleyn [mailto:erich@uruk.org]
Sent: Monday, December 06, 1999 3:52 PM
To: Zook, Nathan; roel@grobbebol.xs4all.nl; khim@sch57.msk.ru
Cc: set@pobox.com; linux-kernel@vger.rutgers.edu
Subject: Re: memory detection problems: 2.0.x vs. 2.2.x



nathan.zook@amd.com wrote:

> Okay, this looks like the problem we are having with some Athlon boards.
My
> guess is that the board supports ACPI, which includes SMAP (int 15/e820)
for
> memory reporting. Depending on the configuration, SMAP compliance may
> require that int 15/e801 memory reporting change. At least one bios
vendor
> has decided to remove int 15/e801 memory reporting instead, which is
> permitted. 2.2.x does not support SMAP (although it may, if I can get
> things together), so we end up with int 15/88 reporting.
>
> POSSIBLE FIX: It may be that if ACPI is turned off, int 15/e801 reporting
> is restored. Since 2.2.x does not support ACPI, this should not result in
> any performance degredation. If this does not work, you are stuck with
> using mem=XXX.

You might want to look at the code in the GRUB bootloader (look at
"http://www.gnu.org/software/grub/". It does all this automatically...
AND has been tested on a bunch of systems (in particular, the SMAP feature
didn't always return contiguous memory as such in the table, so you have
to loop through the table and coalesce the entries, or just add them to
your page available pool and assume there can be multiple separate
sections of available memory).

It turned out to not take that much code, and if you absolutely want to
put the code into the Linux kernel, you can just steal/adapt the code
I wrote.

--
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/

-
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.054 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site