"Ronald G. Minnich" <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
