[SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
Jan Kiszka
jan.kiszka at siemens.com
Mon Mar 19 21:03:09 CET 2012
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
More information about the SeaBIOS
mailing list