Well about it being an EMM386 problem - no, it's DOS itself that maps the
memory incorrectly if it's not filled the way it expects it. EMM386 just asks
DOS for a memory map and tries to find the first free segment. But in this
case, DOS hasn't mapped any segment as free, so EMM386 is unable to d
Also, as for reproduction instruction:
Start MS-DOS and make sure to bypass CONFIG.SYS and AUTOEXEC.BAT.
Then run Microsoft Diagnostics (MSD) and press M for Memory. Look at the Memory
Map: areas that are available, get marked as either "potentially available"
(which means EMM386 will treat them
>>But you're supposed to use e820 or other mechanisms to retrieve the proper
>>memory layout from the firmware.
Well go back to the early 1990's and tell Microsoft and IBM that. :p
DOS as it is, refuses to recognize memory not filled with 0xFF's as free. It
instead thinks such memory is used by O
The problem is specifically about the first 1 MB of RAM. Also, another
related problem is that in all Qemu 1.x versions, segments E000-EFFF,
possibly even D000-DFFF, get used by an Option RAM that can't be
removed. This drastically reduces the amount of available upper memory.
--
You received thi
Yeah, Qemu fills all bytes of the unused memory with 0x00 whereas it
should fill them with 0xFF. This causes DOS to incorrectly interpret
available memory as used by Option RAM, breaking the operation of
EMM386.EXE which then fails to find available upper memory. This also
causes problems with runn
well, actually, memory gets filled with the wrong byte, pardon my
original post.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1180923
Title:
unused memory filled with 0x00 instead of 0xFF
Status
