qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SeaBIOS] [Qemu-devel] QEMU regression problems


From: Kevin O'Connor
Subject: Re: [SeaBIOS] [Qemu-devel] QEMU regression problems
Date: Mon, 19 Apr 2010 21:26:19 -0400
User-agent: Mutt/1.5.20 (2009-08-17)

On Mon, Apr 19, 2010 at 08:19:55AM +0200, Gerhard Wiesinger wrote:
> Kevin O'Connor wrote:
> >The SeaBIOS log would really help.  This can be done by adding:
> >
> >-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
> >
> >to the qemu command line.
> OK, I made some research on the topic. Problem is that QEMM pushes
> the Extended BIOS data area to High RAM on some machines (QEMU,
> P733). Therefore 640k low memory is available and checkit reports
> 640kB + 6kB=646kB EBIOS DATA AREA. Whats strange that on a physical
> Pentium 733 machine this works correctly (details see below and
> attached files), maybe someone can try to find the problem with
> QEMM+Checkit 3.0 (maybe there is still some other BIOS function
> incorrectly implemented). QEMM parameter NOXBDA avoids moving the
> XBDA up to HI RAM and therefore checkit reports 640kB well.
> 
> SeaBIOS seems to be correct (see below and attached patch files and
> description below).
> Total Memory: 256MB (262144kB), Base RAM: 637kB
> Extended BIOS Data Area size: 3 kB, segment=9f40
> 
> SCSI option ROM:
> After option ROMS, Total Memory: 256MB (262144kB), Base RAM: 634kB
> Extended BIOS Data Area size: 6 kB, segment=9e80

Which scsi option rom?  Can you forward the log using the command line
above?  Another thing that may help is increasing the debug level in
seabios (set CONFIG_DEBUG_LEVEL to 8 in src/config.h and recompile).

SeaBIOS will lock parts of ram from 0xc0000-0xfffff so that the option
roms aren't writable.  I wonder if that is confusing qemm when it
tries to locate the ebda into that area.

-Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]