"Ronald G. Minnich" rminnich@lanl.gov writes:
The first problem is this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000bcc (reserved) BIOS-e820: 0000000000000bcc - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 0000000100000000 - 0000000120000000 (usable) 3712MB HIGHMEM available. 896MB LOWMEM available.
Looking at the kernel source these seem to be the sizes of the lowmem and the highmem ranges, and not a count of available ram. All I had handy was 2.4.17 and it reports in the bogus case:
BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000be0 (reserved) BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 0000000100000000 - 00000001e0000000 (usable) Warning only 4GB will be used. Use a PAE enabled kernel. 3328MB HIGHMEM available.
And then it works just fine. So I do not think there except for a bad print statement.
those MEM numbers are quite bogus. The second problem is that it can't find the initrd in the image.
On a good load the initrd is at 2000a000 i.e. 512MB+some, and that puts it on this mem right at memory that doesn't exist.
Ouch how does beoboot decide where to place a ramdisk? I just hard code them at 8MB in mkelfImage, so it looks to me like it is beoboot that cannot handle the situation.
I think it is getting confused early in the game and ending up with an initrd somewhere bogus.
Sounds reasonable. With the one caveat that the kernel does not position the initrd. Which makes beoboot look like the culprit.
Eric