On 11/14/2009 09:47 PM, Kevin O'Connor wrote: > Hi, > > On Thu, Nov 12, 2009 at 01:20:58PM +0200, Naphtali Sprei wrote: > >> I've found a problem with the usage of SeaBIOS/gPXE in Qemu. The >> scenario is when failing to boot from network and falling back to >> booting from hard-disk (-boot nc). The cause of the problem is that >> both SeaBIOS and gPXE (in it's installation phase) uses same stack >> area, 0x7c00. The gPXE code corrupts the SeaBIOS stack, so when >> gPXE returns to SeaBIOS chaos occurs. >> >> Output: "qemu: fatal: Trying to execute code outside RAM or ROM at >> 0x00000000eb300000" >> > Thanks for reporting this. > > We can move the SeaBIOS stack, but it's not clear to me where to move > it to. Bochs bios puts the top of the stack at 0x10000, but this > could potentially conflict with the OS load to 0x7c00. So, in SeaBIOS > the top of stack was moved to 0x7c00 to prevent this conflict. > > Maybe the gPXE developers know where the bios typically places its > stack. > > However, I'm not sure why gPXE doesn't just use the stack it was > given, or allocate the stack space it needs with PMM. >
Something that is likely related, I am seeing reboot failures in seabios's pmm_free. Immediately after loading gpxe, seabios is in an endless loop there, likely due to memory corruption. This is with -smp 2, rebooting Fedora 9 after installation. -- error compiling committee.c: too many arguments to function _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
