Syslinux - Jan 2005 - Re: Problems with loading ramdisk under SYSLINUX 3.05

Petr Vandrovec wrote:
> Hello,
>   one of FreeDOS developers pointed out (in 
>
http://www.vmware.com/community/thread.jspa?threadID=11324&messageID=109507&#109507)
> that FreeDOS does not work under VMware when using ISOLINUX 3.0x.  After 
> looking at their ISO image I downloaded syslinux-3.05, and there seems 
> to be bad bug:
> 
>   You have this in kernel.inc:
> 
> su_code32start  resd 1                  ; 0214 Start of code loaded high
> su_ramdiskat    resd 1                  ; 0218 Start of initial ramdisk
> su_ramdisklen   equ $                   ; Length of initial ramdisk
> su_bsklugeoffs  resw 1                  ; 0220
> su_bsklugeseg   resw 1                  ; 0222
> su_heapend      resw 1                  ; 0224
> su_pad1         resw 1                  ; 0226
> su_cmd_line_ptr resd 1                  ; 0228
> su_ramdisk_max  resd 1                  ; 022C
> 
> But this puts su_ramdisklen at same address as su_bsklugeoffs, and so 
> all items after su_ramdisklen are 4 bytes off!
> 
> Due to this when memdisk from their ISO is loaded, runkernel.inc looks 
> at su_cmd_line_ptr instead of at su_ramdisk_max, finds 0 there, and so 
> loads image at 0 - 0x5A000 = 0xFFFA6000.  But there is no ram at 
> 0xFFFA6000, and so it does not quite work.
> 
> So in addition to the fixing su_ramdisklen in kernel.inc it would be 
> nice if you could verify whether su_ramdisk_max is not smaller than 
> su_ramdisklen, and refuse to load ramdisk when such situation happens.
Well, I actually have a check like that, but this fooled that check too.

*SIGH* so much for thinking I pushed out a known set of changes with 3.05.

What's getting pretty clear is that I can't be relied on to do proper 
testing by myself.  I could really use a set of formal QA volunteers.

	-hpa