Discussion:
Bug#575439: qemu-kvm - Windows NT4 virtual machine stops with BSOD during boot
Michael Tokarev
2010-05-21 12:14:57 UTC
Permalink
This is a guest issue, not kvm issue. See
http://marc.info/?l=qemu-devel&m=127439130431895
And indeed, I tried to set up winNT on two other
machines here, it fails the same way during boot,
with the same STOP: 0x00000003 error (incorrect
multi-processor configuration). It has been fixed
in service pack 6. There's also a workaround in
kvm, to use -cpu qemu64,level=1 (the level is what
matters, not qemu64).
Correction. The original bugreport, about 0x0000003E
code, is something to do with the windows NT reacting
to (slight) hardware change it is running on. This
is something outside of scope of kvm - yes, kvm changes,
and virtual devices it emulates for the guest changes
too, it's just like hardware upgrade (usually leads to
reinstall of windowsNT). At least upgrading kvm from
-72 to -0.12 does not make windowsNT install performed
in kvm-72 to break, it must be some even older than -72
install.

The other problem reported in this thread, about 0x000003
error code, which leads to inability to reinstall the system,
is also due to windowsNT bug.

The recommended course of things is to reinstall windows
NT (or find a way to fix the issue inside it without
reinstalling), for which -cpu qemu64,level=1 is a
work-around for the bug mentioned. After install,
either continue using the level=1 suboption, or apply
service pack 6, which will fix the bug in the guest.

Just to clarify things...

Thanks!

/mjt
Michael Tokarev
2010-05-21 12:28:24 UTC
Permalink
This is a guest issue, not kvm issue. See
http://marc.info/?l=qemu-devel&m=127439130431895
And indeed, I tried to set up winNT on two other
machines here, it fails the same way during boot,
with the same STOP: 0x00000003 error (incorrect
multi-processor configuration). It has been fixed
in service pack 6. There's also a workaround in
kvm, to use -cpu qemu64,level=1 (the level is what
matters, not qemu64).
Correction. The original bugreport, about 0x0000003E
code, is something to do with the windows NT reacting
to (slight) hardware change it is running on. This
is something outside of scope of kvm - yes, kvm changes,
and virtual devices it emulates for the guest changes
too, it's just like hardware upgrade (usually leads to
reinstall of windowsNT). At least upgrading kvm from
-72 to -0.12 does not make windowsNT install performed
in kvm-72 to break, it must be some even older than -72
install.
The other problem reported in this thread, about 0x000003
error code, which leads to inability to reinstall the system,
is also due to windowsNT bug.
Ehm. Another correction.

the two problems:
0x0000003E - invalid smp configuration
this is the guest bug seen during install, fixed in sp6
0x0000001E - inaccessible boot device
this is what you get by changing (even virtual) hardware
on a machine running windows NT

Since the bug mentions both problems.

Please excuse me for the noise: the number of digits in the
error codes puzzled me :)
The recommended course of things is to reinstall windows
NT (or find a way to fix the issue inside it without
reinstalling), for which -cpu qemu64,level=1 is a
work-around for the bug mentioned. After install,
either continue using the level=1 suboption, or apply
service pack 6, which will fix the bug in the guest.
Just to clarify things...
Thanks!
/mjt
Martin Stut
2010-05-25 19:43:21 UTC
Permalink
Today I installed the kvm-qemu update from 0.12.3-dfsg-4 to 0.12.4-dfsg-1.

Unfortunately I still can't start the precious accounting database
VM-guest based on NT4. I also still can't (re)install NT4 SP0.

Here ist my test log:

2010-05-25: update from kvm 0.12.3-dfsg-4 auf 0.12.4-dfsg-1, normal
system start
result: BSOD
*** STOP: 0x0000001E (0xC0000005,0x8001449C,0x00000000,0x8011A95B)
KMODE_EXCEPTION_NOT_HANDLED*** Address 8001449c has base at 80010000 -
hal.dll
attempt: reinstallation from CD (-boot order=dc):
result: same STOP
attempt: -M pc-0.10 -cpu pentium3
result: kvm_run: Exec format error, kvm_run returned -8
attempt: -cpu pentium2
result: kvm_run: Exec format error, kvm_run returned -8
attempt: -cpu qemu32
result: BSOD STOP 0x0000003E
attempt: -cpu pentium
result: kvm_run: Exec format error, kvm_run returned -8
attempt: ohne -cpu
result: BSOD STOP 0x0000003E
attempt: -M pc-0.11 -cpu pentium3
result: kvm_run: Exec format error, kvm_run returned -8
attempt: -M pc-0.11 -cpu qemu64,level=1
result: BSOD STOP 0x0000001E
attempt: -M pc-0.11 -cpu 486
result: kvm_run: Exec format error, kvm_run returned -8


What can I do to continue accounting on the NT4 guest even after
upgrading from kvm version 72+dfsg-5+squeeze1 (works) to something current?
What strategy should I follow to avoid even the slightest change of
(virtual) hardware? I thought, virtualisation was a good idea to keep
legacy systems running.
--
Martin Stut
------------------------------------------------------------------------
DÃŒnsbergstr. 38 Phone: +49-6421-953639
35043 Marburg Email: ***@stut.de
GERMANY Web: www.stut.de <http://www.stut.de/>
Michael Tokarev
2010-05-26 06:45:21 UTC
Permalink
Post by Martin Stut
Today I installed the kvm-qemu update from 0.12.3-dfsg-4 to 0.12.4-dfsg-1.
Unfortunately I still can't start the precious accounting database
VM-guest based on NT4. I also still can't (re)install NT4 SP0.
There was no changes between 0.12.3 and 0.12.4-dfsg-1
related to this problem.
Post by Martin Stut
2010-05-25: update from kvm 0.12.3-dfsg-4 auf 0.12.4-dfsg-1, normal
system start
result: BSOD
*** STOP: 0x0000001E (0xC0000005,0x8001449C,0x00000000,0x8011A95B)
KMODE_EXCEPTION_NOT_HANDLED*** Address 8001449c has base at 80010000 - hal.dll
result: same STOP
What do you mean? Did it work with 0.12.3-dfsg-4,
but fails with 0.12.4?

The 0x0000001E STOP is mentioned all over the 'net, it's
sort of generic error which may mean many different
things. Usually suggesting "buggy driver" or other
reasons of the same theme.
Post by Martin Stut
attempt: -M pc-0.10 -cpu pentium3
result: kvm_run: Exec format error, kvm_run returned -8
This one needs some attention I think.
Post by Martin Stut
attempt: -cpu pentium2
result: kvm_run: Exec format error, kvm_run returned -8
attempt: -cpu qemu32
result: BSOD STOP 0x0000003E
This one will not work, we discovered it already.
NT needs ,level=1 for the cpu definition.
Post by Martin Stut
What can I do to continue accounting on the NT4 guest even after
upgrading from kvm version 72+dfsg-5+squeeze1 (works) to something current?
Martin, please understand that it is not exactly fair to
ask this question. There's very little interest of running
old operating systems. Unless someone skilled enough will
face the same problem, or someone will hire right people
to find and fix the issue, it's unlikely to be fixed. It
is difficult to debug, and it is obvious that we're facing
bugs in windowsNT, and it's very hard to stay bug-compatible.

I'm not saying "go away", not at all. Exactly the opposite,
I'm trying to help. But I never digged this deep, so I
don't know what exactly to do.
Post by Martin Stut
What strategy should I follow to avoid even the slightest change of
(virtual) hardware? I thought, virtualisation was a good idea to keep
legacy systems running.
For now, I see that you need to install at least SP6 on
your winNT machine. For that, try booting it in whatever
kvm which works (maybe with -no-kvm, maybe with ,level=1,
maybe with older version - anything, but not with -no-acpi),
and apply SP6. This will - hopefully - let it to work with
current kvm-0.12, at least it works for me with any sane
-cpu I tried.

This is about 0x3e issue (invalid smp configuration). It
is a genuine bug in winNT, known and fixed in SP6.

Speaking of 0x1e, this is different issue, and I haven't
seen it here. Maybe it's original NT without any service
packs (mine has SP1 integrated into install image), I dunno.
Again, later SP may fix it as well, and again, I dunno.

In any way, installing SP6a is definitely worth a try.

But let's face it: you're walking on the edge of a blade,
and are risking to fall.

About half a year ago I inspected some organization here,
they asked what to do with their IT infrastructure. I found
some dozens of i486 and pentium-based machines running
win95 and an NT-based server, and an old MSDOS-based
accounting program using btrieve(sp) (that works over
IPX protocol). That thing does not work on win2000,
for server winNT is the latest, and for clients it's
win9x. The problem they had is that old hardware stops
working and there's nothing to replace it with, because
that software (win9x) does not work on modern hardware.

I considered using virtualisation technologies, but this
will work only for "transitional period", while they move
to a new software, so that they will be able to run
current OS and their old accounting software inside a
virtual machine.

And the more it works this way, the less chances they
have to convert their system to something current, because
there are less and less specialists available who know both
their old thing and some new, who are able to convert their
data. And it will cost more too.

The bottom line of that inspection is: move. Discussion
is welcome as of _how_, and here we've several ways,
including using kvm or whatnot, but the base does not
change: they need to move.

Yes, when using virtualisation software like kvm, it is
possible to keep running the old system. But IMHO,
the resources required to keep it working (like this one,
dealing with the old bugs) are better spent elsewhere.
Again, just IMHO, you obviously know your situation
better than me.

Thanks!

/mjt
Martin Stut
2010-05-26 17:15:37 UTC
Permalink
Post by Michael Tokarev
Post by Martin Stut
2010-05-25: update from kvm 0.12.3-dfsg-4 auf 0.12.4-dfsg-1, normal
system start
result: BSOD
*** STOP: 0x0000001E (0xC0000005,0x8001449C,0x00000000,0x8011A95B)
KMODE_EXCEPTION_NOT_HANDLED*** Address 8001449c has base at 80010000 - hal.dll
result: same STOP
What do you mean? Did it work with 0.12.3-dfsg-4,
but fails with 0.12.4?
No, it fails in both 0.12.x versions. I tried these combinations, just
in case something would have changed between versions. To be sure I
don't miss something, I wrote all attempts in my (manual) log.

Thanks!
--
Martin Stut
------------------------------------------------------------------------
Dünsbergstr. 38 Phone: +49-6421-953639
35043 Marburg Email: ***@stut.de
GERMANY Web: www.stut.de <http://www.stut.de/>
Martin Stut
2010-05-27 15:43:51 UTC
Permalink
Post by Michael Tokarev
This one will not work, we discovered it already.
NT needs ,level=1 for the cpu definition.
Thanks for emphasizing this. I experimented with a few other options (-M
in particular) and got the guest NT4 (SP6 non-a, I looked at the copy
running on the old KVM version) and the setup (NT4 SP0) running again.
No need to reinstall.

THE SOLUTION IS: *-M pc-0.10 -cpu qemu32,level=1 -smp 1*

THIS COMMAND LINE WORKS: kvm -m 1024 -hda
/backup/qemu/francke4/francke4.img -cdrom
/backup/qemu/francke4/winnt4.iso -M pc-0.10 -cpu qemu32,level=1 -smp 1
-boot order=cd -monitor stdio


Thank you very much for bearing with me.
--
Martin Stut
------------------------------------------------------------------------
Dünsbergstr. 38 Phone: +49-6421-953639
35043 Marburg Email: ***@stut.de
GERMANY Web: www.stut.de <http://www.stut.de/>
Loading...