2.4.19 and sparse e820 map

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at 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