lkml.org 
[lkml]   [1999]   [Dec]   [9]   [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
In article <linux.kernel.AB4CB1CC6547D21197B00008C7F48FB402C10EFE@txexmta0.amd.com>,
<nathan.zook@amd.com> wrote:
>As for forwarding the data, unless all boot loaders did it, it wouldn't make
>a difference--the kernel has to be able to get the data itself.
>
>If you check the archive, you can probably find a posting with a header like
>"I've found a system that explodes e820". I think this is a case. But even
>without such a case in hand, do you really expect all 386 biosen to calmly
>recognize int 15-e801 as an unknown function & return with a carry flag set?
>BTW, I've also been told there is are problems with e801. If you check
>arch/i386/boot/setup.S, you will see an #ifdef around the e820 & e801 code.

E801 is, I'm afraid, a bit of a minefield; it suffered from coming into
existance about the same time as E820 did, and thus a lot of vendors who
implemented E820 just had E801 return bogus nonsense (like the Award
bioses on a bunch of FIC PA210?'s I own, which tell the kernel that
the system has 500+mb of core when it only has 128.)

I suspect that the next round of a E820 memory detect I'll do will
simply blow away E801 instead of ignoring it if E820 works.

>This extra data, however, is by definition spurious today, so we can ignore
>it, so long as we don't overwrite our buffers with it. Such a condition can
>be detected using ecx out, and handled fairly easily.

I believe that you need to pass the size of the memory record in (in ecx)
so unless the BIOS is severely broken it won't randomly walk over memory
no matter how much it wants to return.

____
david parsons \bi/ E820 memory detection for 1.2.13, anyone?
\/

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