[syslinux] pxelinux 5.x, 6.x memtest problem

[Matt Fleming]

On Fri, 28 Jun, at 01:45:13PM, H. Peter Anvin wrote:
> This problem is understood, it just isn't entirely trivial to fix.  The
> problem is that memtest is an "ancient" kernel which has to be loaded at
> a fixed address, but the PXE stack also wants to use the same address.
> This causes issues if one also wants sane error behavior.
 
[Digging up an old thread]

On Wed, 13 Feb, at 09:52:44AM, H. Peter Anvin wrote:
>      Start     Length       Type
> --------------------------------
[...]
> 0x0008ac00 0x00005e00          0
> 0x00090a00 0x000095d0          1
> 0x00099fd0 0x00066030          0
[...]
> Current frag list:
>       Dest        Src     Length
> --------------------------------
> 0x00099fd0 0x001f9140 0x00000016
> 0x00090000 0x001f9a00 0x00000a00
> f: 0x00000016 bytes at 0x00099fd0
> f: 0x00000a00 bytes at 0x00090000
> @: 0x00000016 bytes at 0x001f9140 -> 0x00099fd0
> need: base = 0x00099fd0, len = 0x00000016, reverse = 0, cbyte = 0x00099fd0
> f: 0x00000001 bytes at 0x00099fd0
> O: 0x00000a00 bytes at 0x001f9a00 -> 0x00090000
> Cannot find the chunk containing the critical byte

The thing that I don't find straight forward about this memory map is
that the "type" of the range we want to load the kernel image at,
0x90000, is SMT_UNDEFINED, which means that an entry doesn't exist in
the E820 map for it, right? Likewise, the 0x99fd0 region is
SMT_UNDEFINED. Does the absent memmap entry imply that the PXE stack is
making use of it?

How can we possibly load a kernel at an address for which the BIOS
hasn't given us any information? I can't even see how 4.06 would handle
this case.

-- 
Matt Fleming, Intel Open Source Technology Center