[SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)

[Jan Kiszka]

On 2012-03-19 01:29, Kevin O'Connor wrote:
> 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?

This makes no difference here, still 216 bytes.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux