[syslinux] Re: mboot.c32, weird e820 map on HP blade machine, possible memory corruption

[Ram Yalamanchili]

Hi Tim,

Ok cool. I dont see the memset change in your link for the patch.

I tried with -O0 and still see discrepancies. The data passed to the kernel
seems to be all different from the printf's.

I put a memset as I suggested, and the printf's give 0x0 - 0x0 for all
memory region results printed by mboot's debugging information. I have some
printf's inside my kernel code, which show the data actually being passed is
different from the mboot's printfs:

0x0 - 0x9f40000000000
0xffffffffffffffff - 0xfffffffffffffffe
0xffffffffffffffff - 0xfffffffffffffffe
0xffffffffffffffff - 0xfffffffffffffffe
0xffffffffffffffff - 0xfffffffffffffffe
0xffffffffffffffff - 0xfffffffffffffffe

>From grub, the correct data is supposed to be:

0x0 - 0x9e
0x9f400 - 0xa0000
0xf0000 - 0x100000
0x100 - 0x1fff9
0x1fffa000 - 0x20000000
0xfec00000 - 0xfec10000
0xfee00000 - 0xfee10000
0xffc00000 - 0x100000000

thanks,
Ram

> Message: 1
> Date: Mon, 13 Mar 2006 12:19:58 +0000
> From: Tim Deegan <Tim.Deegan at cl.cam.ac.uk>
> Subject: Re: [syslinux] mboot.c32, weird e820 map on HP blade machine,
> 	possible memory corruption
> To: syslinux at zytor.com
> Message-ID: <20060313121958.GB4133 at tyer.cl.cam.ac.uk>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi,
>
> Thanks for pointing out the memset thing: I've rolled that change into
> the patch at http://www.cl.cam.ac.uk/~tjd21/tmp/shtab.patch
>
> On Sat, Mar 11, 2006 at 12:02:39PM -0800, syslinux-request at zytor.com
> wrote:
> > I compiled mboot.c with a DEBUG defined in the mboot.c file. In the
> funciton
> > init_mmap(), it prints the e820 map and on the HP blade this map values
> come
> > out to be totally random. Some weird numbers which dont make any sense
> at
> > all.
>
> Urgh.  Does it then pass a correct mmap to the kernel or is that corrupt
> too?  Does compiling with -O0 instead of -Os make any difference?
>
> Tim.
>
> --
> Tim Deegan                           (My opinions, not the University's)
> Systems Research Group
> University of Cambridge Computer Laboratory
>