From: G 3 <programmingkidx@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "qemu-devel@nongnu.org qemu-devel" <qemu-devel@nongnu.org>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] Help with Windows NT 4.0
Date: Wed, 16 Aug 2017 19:19:37 -0400 [thread overview]
Message-ID: <C17DC1B9-FE9A-43CD-B84F-51D321209300@gmail.com> (raw)
In-Reply-To: <db1ad643-9dc6-6464-1487-44007b3609ee@redhat.com>
On Aug 15, 2017, at 6:27 PM, Paolo Bonzini wrote:
> On 15/08/2017 20:46, Programmingkid wrote:
>>
>>> On Aug 14, 2017, at 2:51 AM, Paolo Bonzini <pbonzini@redhat.com>
>>> wrote:
>>>
>>> On 13/08/2017 21:13, Programmingkid wrote:
>>>> Lately I found out that Windows NT 4.0 seems to work well with the
>>>> 486 and pentium processors. Using "-cpu 486" made installing it
>>>> actually work. Now I am seeing another issue. When I boot
>>>> Windows NT
>>>> 4.0 I see this error message:
>>>>
>>>> *** STOP: 0x0000007B (0x807A8610,0x00000000,0x00000000,0x00000000)
>>>> INACESSIBLE_BOOT_DEVICE
>>>>
>>>> Would anyone know a way to solve this issue?
>>>
>>> Hervé is probably the best person to answer this question. Maybe
>>> try
>>> installing it with SCSI disks ("-drive if=scsi,id=hd,file=... -drive
>>> if=scsi,id=cd,file=... -device lsi -device scsi-hd,drive=hd -device
>>> scsi-cd,drive=cd").
>>>
>>> Thanks,
>>>
>>> Paolo
>>
>> Thanks for the help. Unfortunately trying to boot from the install
>> CD leads to the INACCESSIBLE_BOOT_DEVICE error when using SCSI.
>
> Try with 0.12.
After doing a lot of bisecting I found a patch that did break Windows
NT 4.0 compatibility long ago. Not sure if it is the problem we face
today. This is it:
commit 2bec46dc97571a3c34b18fe4ca198e7bfbdca41f
Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Nov 24 20:21:41 2008 +0000
vga optimization (Glauber Costa)
Hypervisors like KVM perform badly while doing mmio on
a loop, because it'll generate an exit on each access.
This is the case with VGA, which results in very bad
performance.
In this patch, we map the linear frame buffer as RAM,
make sure it has dirty region tracking enabled, and then
just let the region to be written.
next prev parent reply other threads:[~2017-08-16 23:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-13 19:13 [Qemu-devel] Help with Windows NT 4.0 Programmingkid
2017-08-14 6:51 ` Paolo Bonzini
2017-08-14 7:18 ` Mark Cave-Ayland
2017-08-15 19:26 ` Programmingkid
2017-08-22 15:19 ` Programmingkid
2017-08-15 18:46 ` Programmingkid
2017-08-15 22:27 ` Paolo Bonzini
2017-08-16 16:32 ` G 3
2017-08-16 23:19 ` G 3 [this message]
2017-08-18 4:31 ` Programmingkid
2017-08-18 8:46 ` Artyom Tarasenko
2017-08-18 13:36 ` Programmingkid
2017-08-18 19:23 ` John Snow
2017-08-18 19:48 ` Programmingkid
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=C17DC1B9-FE9A-43CD-B84F-51D321209300@gmail.com \
--to=programmingkidx@gmail.com \
--cc=ehabkost@redhat.com \
--cc=hpoussin@reactos.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).