I'm working on getting the latest Linux distros working well on one of
our prototype machines, however, some of them are failing to boot into
the installer from the CD/DVD images. I've narrowed it down to isolinux
hanging just before displaying the graphical menu. After a little
bisecting between the last version that worked (3.73) and the first
version which was broken (3.74), I found this piece of code that is
responsible for the problem:
=====================================================================---
syslinux-3.73/core/com32.inc 2009-10-12 16:51:06.294747337
-0600
+++ syslinux-3.74/core/com32.inc 2009-10-12 16:51:09.750744468
-0600
@@ -172,13 +172,14 @@
; Now everything is set up for interrupts...
+ push dword [HighMemSize] ; Memory managed by
Syslinux
push dword com32_cfarcall ; Cfarcall entry point
push dword com32_farcall ; Farcall entry point
push dword (1 << 16) ; 64K bounce buffer
push dword (comboot_seg << 4) ; Bounce buffer address
push dword com32_intcall ; Intcall entry point
push dword command_line ; Command line pointer
- push dword 6 ; Argument count
+ push dword 7 ; Argument count
sti ; Interrupts OK now
call pm_entry ; Run the program...
; ... on return, fall through to com32_exit ...
=====================================================================
Removing these changes in the 3.83 release allows the prototype machines
to boot the installer, but I'm not sure why these changes are needed
since it works on other (released) machines I have access to. I'm
writing the list because I would like to determine if this is a firmware
bug that we can fix before we release, or a bug in isolinux that this
machine aggrevates?
Thanks,
Bryan
On 10/13/2009 02:15 PM, Stillwell, Bryan wrote:> I'm working on getting the latest Linux distros working well on one of > our prototype machines, however, some of them are failing to boot into > the installer from the CD/DVD images. I've narrowed it down to isolinux > hanging just before displaying the graphical menu. After a little > bisecting between the last version that worked (3.73) and the first > version which was broken (3.74), I found this piece of code that is > responsible for the problem: > > =====================================================================> --- syslinux-3.73/core/com32.inc 2009-10-12 16:51:06.294747337 > -0600 > +++ syslinux-3.74/core/com32.inc 2009-10-12 16:51:09.750744468 > -0600 > @@ -172,13 +172,14 @@ > > ; Now everything is set up for interrupts... > > + push dword [HighMemSize] ; Memory managed by > Syslinux > push dword com32_cfarcall ; Cfarcall entry point > push dword com32_farcall ; Farcall entry point > push dword (1 << 16) ; 64K bounce buffer > push dword (comboot_seg << 4) ; Bounce buffer address > push dword com32_intcall ; Intcall entry point > push dword command_line ; Command line pointer > - push dword 6 ; Argument count > + push dword 7 ; Argument count > sti ; Interrupts OK now > call pm_entry ; Run the program... > ; ... on return, fall through to com32_exit ... > =====================================================================> > Removing these changes in the 3.83 release allows the prototype machines > to boot the installer, but I'm not sure why these changes are needed > since it works on other (released) machines I have access to. I'm > writing the list because I would like to determine if this is a firmware > bug that we can fix before we release, or a bug in isolinux that this > machine aggrevates? >Sounds like you're using stale .c32 files -- your .c32 files need to match your isolinux.bin. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
On 10/13/2009 02:15 PM, Stillwell, Bryan wrote:> > Removing these changes in the 3.83 release allows the prototype machines > to boot the installer, but I'm not sure why these changes are needed > since it works on other (released) machines I have access to. I'm > writing the list because I would like to determine if this is a firmware > bug that we can fix before we release, or a bug in isolinux that this > machine aggrevates? >The other possibility is that you have a broken memory map. Could you read out the output of meminfo.c32? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.