RE: Possible workaround for buggy E801 call in 2.2.x

nathan.zook@amd.com
Tue, 21 Dec 1999 10:54:08 -0600


Actually, ordering them isn't so hard, and neither is testing for overlap.
What you DON'T want is to test it all in setup.S. Rememer this is run-once
code, freeded after startup. While we DON'T want to waste cycles, we don't
want to try to run an operating system with a corrupt mem map, either.

Memory dectection is so fundamental that I think it should have config
options right under "processor type". But it's not exactly my call...

Nathan

-----Original Message-----
From: Prashant TR [mailto:prashant_tr@yahoo.com]
Sent: Tuesday, December 21, 1999 10:48 AM
To: David Parsons; Zook, Nathan
Cc: Linux Kernel Mailing list
Subject: Re: Possible workaround for buggy E801 call in 2.2.x

> One of the FIC slot-1 motherboards of recent vintage has exactly
> that (the VB-601; I can't say the vintage of the bios, because
> all the VB-601's I administer are parked about 4 miles north of
> me right now.) That's what provoked the e820 implementation in
> the first place -- e801 would tell me I had half a gig, 88 would
> tell me 64mb, and e820 returns a memory map containing the correct
> 128mb of system ram.

If the E820 returns the memory addresses and if they happen to be
in increasing order without an overlap, this should be quite sufficient
to make sure if the call is correctly supported (not broken). But doing
this can be quite a problem and would add unnecessary code.

If we were talking of having any options disabled by default, then I
guess it should be the E801 call (considering the frequency of errors
of E820 and E801).

__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

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