Re: [syslinux] SYSLINUX 2.09-pre11

Re: [syslinux] SYSLINUX 2.09-pre11

[H. Peter Anvin]

Andrea Mazzoleni wrote:
> On 02/05, H. Peter Anvin wrote:
> 
>>Please test it out.  Some time over the weekend I'm going to do a sweep 
>>for bug fixes I've forgotten and otherwise I'd like to release 2.09 next 
>>week.
> 
> Please consider to compare the behaviour of the SYSLINUX mem= option with
> the Linux kernel behaviour. I've rechecked it a lot of time, and I'm sure that
> there is a difference.
> 
> In the kernel function parse_cmdline_early() in the file arch/i386/kernel/setup.c
> the "mem=" option is used to only reducing (and never expanding) the memory map
> calling the limit_regions() function. This happen also if E820 is not available.
> 
> Instead, SYSLINUX uses the "mem=" option also for expanding the memory map
> over the value read from the BIOS.
> 
> Please note that this is only true for the simplest format of the "mem=" option
> like "mem=512M". Other formats like "mem=512M@512M" have different behaviours
> because add_memory_region() is called instead of limit_regions().
> 
> Also note that if E820 is not present, a fake E820 memory map is created
> in the setup_memory_regions() kernel function in arch/i386/kernel/setup.c.
> This is the fake memory map on which the limit_regions() function operates.
> That exactly happen is that copy_e820_map() returns -1 because "nr_map" is
> set to 0 in the arch/i386/boot/setup.S file if E820 is not present.
> 

This is unfixable, because someone fucked up and re-used a 
well-established protocol-defined option for another purpose.  E.g. 
"mem=512M" has meant exactly that (and was/is widely used to specify 
that memory should be added up to 512M).

Since the behaviour you describe is kernel-version-dependent, IT CANNOT 
BE FIXED IN THE BOOTLOADER, and whomever thought it was a good idea to 
mess with mem= should be taken out and shot.

	-hpa