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. I think Microsoft uses their own ACPI implementation in Windows rather than the Intel reference ACPI CA code. (At the very least I know they have their own ASL compiler.) Also, the majority of x86 hardware vendors, aside from Apple, only validate their systems with Windows because they perceive their target market as being comprised mainly of Windows users. Yes, even today. (Go count how many machines have Windows logo stickers on them. Now go count how many have little Linux or FreeBSD logo stickers on them. Big difference, isn't there.) As a result, ACPI tables or AML code will often have little quirks that don't seem to bother Windows but which break everything else. In more egregious cases, the ASL might even be effectively written to say "if (OS == Windows) {work right} else {swallow own tongue}." Given that ACPI is supposed to be an industry standard, you would think this wouldn't be a problem. But it's a _big_ and complicated standard, and as with any big and complicated standard, getting everyone to interpret it 100% unambiguously is hard. The same is true of UEFI. Some of these issues would be avoided if the hardware manufacturers went to the trouble of testing their ACPI blobs with the Intel reference code and tools instead of just the Microsoft ones. But Microsoft has no incentive to compel logo program participants to do this, and there isn't "UEFI Forum" logo program (as far as I know). Even if there were, they might not feel obliged to comply with it anyway, because If It Works With Windows, It Must Be Okay. I'm sorry I can't offer anything constructive to help you solve this particular problem though (other than be persistent and add lots of debug instrumentation), but I'm glad to see that at least someone is bothering to test the 32-bit build. -Bill > Boot issues often have to do with ACPI details. It > has also had some quirks re. what it expects in the EFI memory map, > although those have mostly related to really large systems (eg. PCIe > segment layout.) > > I see you CC'd some folks at Microsoft. Hopefully they will be able to > give you more specific advice. -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, [email protected] | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
