Re: [Qemu-devel] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)

[Kevin O'Connor <kevin@koconnor.net>]

On Mon, Feb 27, 2012 at 04:25:09PM +0100, Jan Kiszka wrote:
> On 2012-02-27 10:51, Daniel P. Berrange wrote:
> > I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following
> > crash:
> > 
> > # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img  -m 1 -curses
> > iPXE v1.0.0-591-g7aee315
> >                                  iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+00000000+00000000 C900
> > 
> >                                  Booting from Floppy..
> > .                                qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000001000effff
> > 
> > EAX=ffffffff EBX=ffffffff ECX=0000c934 EDX=00000068
> > ESI=00006801 EDI=00000000 EBP=0000002b ESP=0000fff5

I traced this down, and it appears to be a stack size issue.  It looks
like MSDOS calls "int 0x13" with 229 bytes of stack space during its
boot.  On my build gcc generates the handle_13() function with a
maximum of 140 bytes of stack space utilized (according to
tools/checkstack.py).  On your build, gcc created it with a maximum of
216 bytes.  The entry functions use 42 bytes of stack space.  Add it
up and you can see that the additional stack space that gcc used
caused %esp to wrap and the stack was corrupted.

I'm not sure how to best work around this.  One way is to sprinkle
"noinline" keywords through disk.c.  (It seems like gcc got in trouble
on your build by inlining many functions into disk_13().)  Another way
would be to jump into the extra stack (the disk code already uses its
own stack) earlier in the handle_13 code.

Also, can you see what happens if you change "--param
large-stack-frame=4" to "--param large-stack-frame=0" in the build?

-Kevin