[syslinux] "keeppxe" broken in 3.74 - short-cycle 3.75

[Dag Wieers]

On Tue, 14 Apr 2009, Dag Wieers wrote:

> On Tue, 14 Apr 2009, H. Peter Anvin wrote:
>
>>  It appears that the 3.74 completely broke the "keeppxe" directive -- not
>>  due to the command-line parser, but due to mishandling of the flag later.
>>
>>  I consider this to be severe enough to do a short-cycle 3.75.  As a
>>  result, I would like help with:
>>
>>  a) are there any other bugs that snuck through?
>>  b) once I have a 3.75-pre1, I would really appreciate help testing it.
>>
>>  The goal is to have 3.75 final before the end of the week.
>
> I think I found one issue with syslinux 3.74 memdisk which we did not have 
> with syslinux 3.73 memdisk. When loading the same PCDOS harddisk image with 
> 3.74 memdisk using:
>
> ----
> label pcdoshd
>   menu label ^DOS image with updates and drivers (pcdoshd)
>   kernel memdisk
>   append initrd=img/pcdoshd.imz harddisk
> ----
>
> it fails with:
>
> ----
> MEMDISK 3.74 2009-04-09  Copyright 2001-2009 H. Peter Anvin et al
> e820:  0000000000000000 000000000009d400 1 [1]
> e820:  000000000009d400 0000000000002c00 2 [1]
> e820:  00000000000e0000 0000000000020000 2 [1]
> e820:  0000000000100000 00000000d7eb0580 1 [1]
> e820:  00000000d7fd0000 0000000000030000 2 [1]
> e820:  00000000d7fb0580 000000000001fa80 3 [1]
> e820:  0000000100000000 0000000128000000 1 [1]
> e820:  00000000e0000000 0000000010000000 2 [1]
> e820:  00000000fec00000 0000000001400000 2 [1]
> Ramdisk at 0xd758d000, length 0x0099590e
> Moving compressed data from 0xd758d000 to 0xd661aa00
> gzip image: decompressed addr 0xd6fb0400, len 0x01000000: ok
> command line: initrd=img/pcdoshd.imz harddisk BOOT_IMAGE=memdisk
> Disk is hard disk 0, 16384 K, C/H/S = 16/64/32, EDD on, read-write
> Using safe INT 15h access to high memory
> Total size needed = 2464 bytes, allocating 3K
> Old dos memory at 0x9d400 (map says 0x9d400), loading at 0x9c800
> 1588: 0xffff  15E801: 0x3c00 0xd5fb
> INT 13 08: Success, count = 1, BPT = 0000:0000
> old: int13 = f0007853  int15 = f000f859  int1e = f000efc7
> new: int13 = 9c80000a  int15 = 9c800391  int1e = f000efc7
> Loading boot sector... booting...
> Missing operating system
> ----
>
> while using 3.73 memdisk I get (what's still on screen):
>
> ----
> MEMDISK 3.73 2009-01-25  Copyright 2001-2009 H. Peter Anvin
> e820:  0000000000000000 000000000009d400 1 [1]
> e820:  000000000009d400 0000000000002c00 2 [1]
> e820:  00000000000e0000 0000000000020000 2 [1]
> e820:  0000000000100000 00000000d7eb0580 1 [1]
> e820:  00000000d7fd0000 0000000000030000 2 [1]
> e820:  00000000d7fb0580 000000000001fa80 3 [1]
> e820:  0000000100000000 0000000128000000 1 [1]
> e820:  00000000e0000000 0000000010000000 2 [1]
> e820:  00000000fec00000 0000000001400000 2 [1]
> Ramdisk at 0xd758e000, length 0x0099590e
> Moving compressed data from 0xd758e000 to 0xd661aa00
> gzip image: decompressed addr 0xd6fb0400, len 0x01000000: ok
> command line: initrd=img/pcdoshd.imz harddisk BOOT_IMAGE=memdisk
> MEMDISK: Image seems to have fractional end cylinder
> Disk is hard disk 0, 16384 K, C/H/S = 32/16/63, EDD on, read-write
> Using safe INT 15h access to high memory
> Total size needed = 2468 bytes, allocating 3K
> Old dos memory at 0x9d400 (map says 0x9d400), loading at 0x9c800
> 1588: 0xffff  15E801: 0x3C00 0xd5fb
> INT 13 08: Success, count = 1, BPT = 0000:0000
> old: int13 = f0007853  int15 = f000f859  int1e = f000efc7
> new: int13 = 9c80000a  int15 = 9c800392  int1e = f000efc7
> Loading boot sector... booting...
> Starting PC DOS...
> ----
>
> Spot the 4 differences :) (Hint: ramdisk location, C/H/S, "Total size", new 
> int15)
>
> Tested on 3 different systems (x3650, x3850m2 and a blade HS20).
> If needed I can share the pcdoshd image with you. I hope this is useful.

It works on all systems if I manually specify the C/H/S as being 32/16/63 
(just like 3.73 memdisk behaved). So I guess this is a regression.

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]