On 09/03/2015 12:59 PM, Bill Paul wrote:
Of all the gin joints in all the towns in all the world, Brian J. Johnson had
to walk into mine at 08:51:20 on Thursday 03 September 2015 and say:
On 09/03/2015 05:08 AM, Laszlo Ersek wrote:
Hi,
64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
machine type of QEMU has "always" worked, and we recently fixed "q35"
too.)
However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
of the QEMU machine type. The error message I'm getting is:
http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png
According to <https://msdn.microsoft.com/en-us/library/cc704588.aspx>,
the error code 0xc0000185 means "STATUS_IO_DEVICE_ERROR".
I also tried with Windows 10:
http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png
Here I get 0xc000000d, "STATUS_INVALID_PARAMETER".
The Windows ISOs I tried with were:
- en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
- en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso
Can someone please help me debug this? The difference between x64 and
x86 is "inexplicable".
I've worked through some firmware issues on older MS releases, but never
Windows 8 or 10. So this advice may be out of date. Do you know if
Windows got through the boot loader and is starting the kernel? If so,
you can turn on extra debug messages to show the drivers as they are
loading. That can give you some good clues. If that's not enough, you
can enable remote debugging and use MS's debuggers (eg. WinDbg) and
symbol tables to get an idea of the call chain which is failing. It's
been a long time since I've done this, so I'm rusty on the specifics...
searching on msdn.microsoft.com should get you going.
Historically, Windows has been extremely picky about ACPI tables, much
more so than Linux.
No: historically hardware vendors have been insufficiently picky about
creating their ACPI tables, leading to what I have not-so-affectionately named
the "If It Works With Windows, It Must Be Okay" syndrome.
It cuts all ways: for vendors which do focus on Linux (such as SGI),
Windows tends to get broken. (And it's a lot harder to debug a broken
Windows boot, as Laszlo is finding out.) Both OSes have been guilty of
making assumptions which violate the relevant specs (UEFI, ACPI, etc.)
And yes, h/w vendors have had plenty of firmware bugs of their own.
Sigh... the world is messy.
--
Brian J. Johnson
--------------------------------------------------------------------
My statements are my own, are not authorized by SGI, and do not
necessarily represent SGI’s positions.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
