Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Jun 21, 2010 at 11:07:31PM -0700, H. Peter Anvin wrote:
> On 06/21/2010 10:22 PM, Josh Triplett wrote:
> > 
> > How might I diagnose this further?  What might cause Linux to refuse to
> > use the e820 and e801 results provided by GRUB, but accept the ones
> > provided by the BIOS?
> > 
> 
> This is interesting... you apparently have a ACPI 3-style e820 BIOS as
> evidenced by the [1] markers, but Grub presents it as legacy style.

Interesting!  I didn't know until now that that system supported the
ACPI 3-style e820.  (Looks like it doesn't actually use that mechanism
to disable any regions, though, fortunately.)

And yes, GRUB always provides 20-byte e820 entries, never larger,
regardless of what the caller asks for.

> Now, the kernel shouldn't care, but this at least gives a clue.
> 
> Something that might be worthwhile is to add printf's to the kernel's
> e820-parsing routine (in arch/x86/boot/e820.c) and figure out why it
> doesn't like the output.  It's a bit strange that meminfo would produce
> sensible-looking output (well, legal, at least; presenting a two-byte
> range is rather beyond crazy, and so forth) and the kernel wouldn't
> accept it, as the code is intentionally very similar.

Do you mean arch/x86/kernel/e820.c ?  OK, will do.

In the failure case Linux prints the memory map as "BIOS-88".  It looks
like that can only happen if the call to append_e820_map fails.  That in
turn looks like it can only happen if the number of map entries becomes
less than 2 (and since it shouldn't start that way that would have to
happen in sanitize_e820_map), or if 64-bit overflow occurred in the
memory map when adding the start and size fields.

I'll investigate further and try to figure out exactly what caused Linux
to refuse to use the e820 map.

- Josh Triplett