Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
I managed to reproduce the problem using stock upstream kernels and
defconfig, and with defconfig (and no initramfs) the kernel managed to
use little enough memory that it booted successfully with <64MB of RAM.
Investigating, I found that Linux decided not to use e820, and instead
decided to use the older BIOS function 0x88, which cannot report more
than 64MB of RAM.
With some investigation and bisection, I managed to track the problem
down to the following commit:
Author: H. Peter Anvin <email@example.com>
Date: Sat Mar 28 13:53:26 2009 -0700
x86, setup: ACPI 3, BIOS workaround for E820-probing code
Impact: ACPI 3 spec compliance, BIOS bug workaround
The ACPI 3 spec added another field to the E820 buffer -- which is
backwards incompatible, since it contains a validity bit.
Furthermore, there has been at least one report of a BIOS which
assumes that the buffer it is pointed at is the same buffer as for the
previous E820 call. Therefore, read the data into a temporary buffer
and copy the standard part of it if and only if the valid bit is set.
Signed-off-by: H. Peter Anvin <firstname.lastname@example.org>
A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds <64MB
of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^
successfully finds all 4GB of RAM.
Also note that newer upstream kernels, including v2.6.35-rc3, fail as
well. Since later kernels revert part of the above commit, the issue
must lie with the parts of the commit not reverted.
And, again, I can reproduce this using the stock upstream GRUB2 1.98
release built from source, by booting it from a USB key, and then
booting the disk MBR via:
drivemap (hd1) (hd0)
Nothing special about drivemap here; anything that uses grub's mmap
module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will
cause grub to hook e820 and trigger this bug. However, in stock grub,
only drivemap does this.
- Josh Triplett