[syslinux] PXE looping on localboot

[Vanush Misha Paturyan]

On Tue, 29 May 2012 11:18:55 -0700 "H. Peter Anvin" <hpa at zytor.com>
wrote:

> On 05/29/2012 10:11 AM, Vanush Misha Paturyan wrote:
> > 
> > Got this after doing "git bisect":
> > 831f1a04fbbbb1f65d95858b1b435325f67981f2 is the first bad commit
> > commit 831f1a04fbbbb1f65d95858b1b435325f67981f2
> > Author: H. Peter Anvin <hpa at zytor.com>
> > Date:   Fri Feb 12 13:37:20 2010 -0800
> > 
> >     pxelinux: move the stack to avoid AMI BIOS bug
> >     
> >     There is apparently some AMI BIOSes which leave a BEV stack just
> >     below 7c00h, which means that they can't return from the PXE
> > NBP. Thus, for PXELINUX, move the stack down a few kilobytes.
> >     
> >     This particularly refers to the "rouilj/ops12" system my private
> >     sysdump archive.
> >     
> >     Reported-and-tested-by: John Rouillard <rouilj at renesys.com>
> >     Signed-off-by: H. Peter Anvin <hpa at zytor.com>
> > 
> > :040000 040000 a4eca2ce83128152f91d3d7faa7647f5ef6a67df
> > c9e89c7e7e44b376c41648d7858fbd726d58b936 M	core
> > 
> > the first "bad" pxelinux reports itself as PXELINUX 3.85
> > pre9-4-g831f1a0
> > 
> 
> OK, this is highly interesting, as this implies yet another BIOS which
> squats on memory it has no right to mess with.
> 
> Could you try the attached patch and see if it works?
> 
> 	-hpa

No luck, system still loops instead of booting from the localhost. Was
the change to STACK_TOP a random shift or is there a logic to it? I'm
attaching an output of meminfo.c32 to this email, in case it can help.
I also found memdump.com file (in memdump directory), with README
claiming it can generate a memory dump. Will it be useful in any ways?
And if yes - which address ranges to dump?

Misha.

-- 
Vanush "Misha" Paturyan
Senior Technical Officer
Room 1.37
Computer Science Department
NUI Maynooth
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: meminfo.txt
URL: <http://www.zytor.com/pipermail/syslinux/attachments/20120530/89e7fe92/attachment.txt>