qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: "Alain Ribière" <alain_ribiere@yahoo.com>
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re : [SeaBIOS] : Memory problem with Qemu/SeaBIOS
Date: Tue, 8 May 2012 18:06:31 -0400	[thread overview]
Message-ID: <20120508220631.GA28784@morn.localdomain> (raw)
In-Reply-To: <1336495676.9684.YahooMailNeo@web130104.mail.mud.yahoo.com>

On Tue, May 08, 2012 at 09:47:56AM -0700, Alain Ribière wrote:
> Thanks for your answer.
> 
> Here is the debug log in attachement.
> I disabled the debug on the screen shot I sent because I noticed I could get a bit more memory without it.
> With the debug on, I got :
> Banked Window  416K at 3800:0 segment
> and a free memory of 15680K
> 
> I'll try to find what confuses C-DOS. It reacts a bit strangely... 
> When I add or remove options from the SeaBIOS, the memory avalaible 
> change and the size of banked window changes too. So I hoped there was a way to have enough memory to run my application...

The options don't impact SeaBIOS' memory usage, so this reafirms my
guess that what you are seeing is a secondary effect.  As a guess,
this could be stack usage - some old program call the bios with very
small stacks and if the stack overflows silent corruption can occur.
The fact that you're seeing different memory layouts with random
changes to config options could be due to different options causing
the compiler to layout the stack slightly differently and thus causing
slightly different corruption - just a guess.

The other thing I noticed with your C-DOS image is that it doesn't
know about the EBDA and uses that memory for its own purposes.  Thus,
the seabios runtime usage of the ebda along with c-dos could cause
conflicts.  I don't think this is the cause of your current issue
though as some moving the ebda in some quick tests I ran doesn't seem
to impact the output of "stop".

> Otherwise, I will have to stuck with Qemu 0.11 and PC-BIOS.
> 
> Do you know if there is any DOS utility to get the memory map ?

I'm not familiar with DOS utilities.  You could ask on the freedos
mailing list.

-Kevin

  reply	other threads:[~2012-05-08 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 15:58 [Qemu-devel] : Memory problem with Qemu/SeaBIOS Alain Ribière
2012-05-08  0:55 ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2012-05-08 16:47   ` [Qemu-devel] Re : " Alain Ribière
2012-05-08 22:06     ` Kevin O'Connor [this message]
2012-05-09 15:57       ` [Qemu-devel] Re : " Alain Ribière
2012-05-10  0:44         ` Kevin O'Connor
2012-05-10  1:19           ` Kevin O'Connor
2012-05-10 13:56             ` [Qemu-devel] Re : " Alain Ribière

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120508220631.GA28784@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=alain_ribiere@yahoo.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).