qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: Problem with DOS application and 286 DOS Extender appli


From: Gerhard Wiesinger
Subject: [Qemu-devel] Re: Problem with DOS application and 286 DOS Extender application
Date: Sun, 13 Feb 2011 15:06:44 +0100 (CET)
User-agent: Alpine 2.02 (LFD 1266 2009-07-14)

Hello,

After some fortune I found out that also Turbo Debugger 286 doesn't work under plain DOS 6.22 (without any memory mananger just pressing F5) or with some memory mananagers (HIMEM.SYS, EMM386, QEMM386).

Error message is:
Error 266 loading D:\DIR\TD286.EXE into extended memory.

So it looks like that there is a major issue with extended memory. Any ideas how to fix or how to find the problem and fix it?

Version is latest seabios and QEMU from git as of now (own builds).

I'm pretty sure that it is the same reason that the 286 DOS Extender application doesn't work.

For full reference of the previously discussed have a look here:
http://www.mail-archive.com/address@hidden/msg29518.html
http://www.mail-archive.com/address@hidden/msg29465.html

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/


On Wed, 14 Apr 2010, Jan Kiszka wrote:

Jamie Lokier wrote:
Gerhard Wiesinger wrote:
It is a non public, proprietary application which uses the Ergo Computing
286 DOS Extender. I guess some other application which use the same DOS
extender have the same problem. So best thing is to find another
application which uses the Ergo Computing 286 DOS Extender, too.

The 286 was obsolete 20 years ago, although code depending on it
persisted for some years after.

I'm fairly sure the number of people using (or trying to use) Qemu
with 286-specific code is very small indeed, so unfortunately for a
286 problem, you will need to help reproduce it as much as you can for
it to be fixed.

In some scenarios, we use QEMU in emulation mode for such a legacy guest
(16-bit protected mode), but we mostly run it in KVM mode these days. It
works fairly well under QEMU, but also we did not explore all corner cases.


Note that Qemu doesn't emulate segments properly even for 32-bit x86
code, and 16-bit (286) code depends on that all the more.  That may be
the problem.

More precisely: QEMU does not check for segment limits. This can be a
problem with buggy or pedantic guests, but usually one tried to avoid
triggering this anyway. I once wrote a crude patch to add this, but it
had significant performance impact and did not properly make use of the
TCG to optimize the checks. You'll find it in the archives (but I guess
it no longer applies).


Or it may be the "reset using keyboard controller and BIOS" method
used to switch from protected mode to real mode on a 286 is not
implemented properly, or is not supported by the BIOS properly.

Or it may simply be a bug in 16-bit task segment switching or
something like that, which is quite complex and so rarely used that it
might never have been properly tested.

Task switching looks fairly stable in QEMU (in contrast to KVM where we
just ran into some more corner cases).


Did you try running the application under Bochs, which has a more
accurate emulation of very old x86 CPUs?

-- Jamie


That said, having some test case to reproduce the issue is essential.
I'm willing to have a look if you can provide such thing (publicly or
privately). Before that, you could already try building QEMU with
--enable-debug and run it with "-d exec,int". The generated
/tmp/qemu.log may point out where things go wrong (usually where faults
starts to occur).

Jan





reply via email to

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