This is not really a BUG of GRUB... it's just that BIOS tables are
getting bigger!

Memtest86(+) uses the "standard" linux kernel image format, so it it can
be loaded easily by boot loaders such as Lilo and Grub...

The format is:
	512 byte of boot sector
	512 * X bytes of setup (where X is usually 4)
	Y bytes of kernel image

A zImage kernel will be loaded at address 0x10000 (64k) while a bzImage
will be loaded at 0x10000 (1MB).

Memtest uses the old format.

The boot loader also loads a copy of boot sector and setup sectors at
0x90000 (and then execute the setup code):

        |                        |
0A0000  +------------------------+
        |  Reserved for BIOS     |      Do not use.  Reserved for BIOS EBDA.
09A000  +------------------------+
        |  Stack/heap/cmdline    |      For use by the kernel real-mode code.
098000  +------------------------+
        |  Kernel setup          |      The kernel real-mode code.
090200  +------------------------+
        |  Kernel boot sector    |      The kernel legacy boot sector.
090000  +------------------------+
        |  Protected-mode kernel |      The bulk of the kernel image.
010000  +------------------------+
        |  Boot loader           |      <- Boot sector entry point 0000:7C00
001000  +------------------------+
        |  Reserved for MBR/BIOS |
000800  +------------------------+
        |  Typically used by MBR |
000600  +------------------------+
        |  BIOS use only         |
000000  +------------------------+

For the details read this:
	http://lxr.linux.no/source/Documentation/i386/boot.txt

So, basically, this layout assumes that memory up to address 0x9A000 can be used.


The problem is that the newer BIOSes are reserving more and more space
in the top addresses below 640k (low memory), so this layout got
broken... and GRUB cannot do anything about it.

I hit this problem a few days ago switching from an "old" Athlon64
based system to a Core2Duo base one.


If you have an x86_64 system you shold have something like this in the
"dmesg" (it's not printed on x86 if I rember correctly, you can look at
"/proc/iomem" anyway):

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[    0.000000]  BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003e599000 (usable)
[    0.000000]  BIOS-e820: 000000003e599000 - 000000003e5a6000 (reserved)
[    0.000000]  BIOS-e820: 000000003e5a6000 - 000000003e655000 (usable)
[    0.000000]  BIOS-e820: 000000003e655000 - 000000003e6a6000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003e6a6000 - 000000003e6ab000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003e6ab000 - 000000003e6ac000 (usable)
[    0.000000]  BIOS-e820: 000000003e6ac000 - 000000003e6f2000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003e6f2000 - 000000003e6ff000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003e6ff000 - 000000003e700000 (usable)
[    0.000000]  BIOS-e820: 000000003e700000 - 000000003f000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)


This table is provided by the BIOS and basically tells what memory
regions can or can't be used by the system (because reserved by BIOS,
for example).

The first line tells that, on my system, the limit of usable low memory
is 8f000, which breaks the above layout assumption...

On my Athlon64 based machine (ASUS K8VSE Deluxe) it was 9FC00, and in
fact it worked.


Conclusion: memtest86 should use some other method of loading...


PS: it's a bit odd to have 1GB of memory and read that a <100k thing
"cannot fit into memory" ;)

-- 
	Paolo Ornati
	Linux 2.6.20-rc2 on x86_64