Am 12.04.23 um 14:18 schrieb Igor Mammedov: > On Thu, 30 Mar 2023 13:58:22 +0200 > Fiona Ebner <f.eb...@proxmox.com> wrote: > >> Am 30.03.23 um 10:22 schrieb Igor Mammedov: >>> On Tue, 28 Mar 2023 14:58:21 +0200 >>> Fiona Ebner <f.eb...@proxmox.com> wrote: >>> >>>> >>>> Hi, >>>> while trying to reproduce another issue, I ended up with a Windows 10 >>>> guest that would boot with QEMU 7.0, but get stuck after the Windows >>>> logo/spinning circles with QEMU 7.1 (also with 8.0.0-rc1). Machine type >>>> is pc-i440fx-6.2[0]. Bisecting led to this commit. >>>> >>>> It only happens the first time the VM is booted, killing the process and >>>> re-trying always worked afterwards. So it's not a big deal and might >>>> just be some ACPI-related Windows quirk. But I thought I should ask here >>>> to be sure. >>>> >>>> For bisecting, I restored the disk state after each attempt. While >>>> getting stuck sometimes took 3-4 attempts, I tested about 10 times until >>>> I declared a commit good, and re-tested the commit before this one 15 >>>> times, so I'm pretty sure this is the one where the issue started >>>> appearing. >>>> >>>> So, anything that could potentially be wrong with the commit or is this >>>> most likely just some Windows quirk/bug we can't do much about? >>>> >>>> If you need more information, please let me know! >>> >>> Please describe in more detail your setup/steps where it reproduces >>> (incl. Windows version/build, used QEMU CLI) so I could try to reproduce it >>> locally. >>> >>> (in past there were issues with German version that some where >>> experience but not reproducible on my side, that resolved with >>> upgrading to newer QEMU (if I recall correctly issue was opened >>> on QEMU's gitlab tracker)) >>> >> >> Windows 10 Education >> Version 1809 >> Build 17763.1 >> >> It's not the German ISO, I used default settings (except location >> Austria and German keymap) and I don't think I did anything other than >> shutdown after the install was over. >> >> The command line is below. I did use our patched QEMU builds when I got >> into the situation, but I don't think they touch anything ACPI-related >> and bisecting was done without our patches on top. >> >> I tried to reproduce the situation again from scratch today, but wasn't >> able to. I do still have the problematic disk (snapshot) where the issue >> occurs as an LVM-Thin volume. If you'd like to have access to that, >> please send me a direct mail and we can discuss the details there. > > I couldn't reproduce the issue on my host either. > If you still have access to 'broken' disk image, you can try to enable > kernel debug mode in guest and try to attach with debugger to it to see > where it is stuck. > > quick instructions how to do it: > https://gitlab.com/qemu-project/qemu/-/issues/774#note_1270248862 > or read more extensive MS docs on topic. >
Hmm, I guess I won't be able to enable kernel debug mode without losing the problematic state of the image. The VM only gets stuck during the first boot attempt. Still, I wanted to give it a shot in the hope I can trigger it again when shutting down with QEMU 6.2.0 and booting with QEMU 7.1.0. I made a copy of the VM intending to use it as the debug host, but didn't get the COM port to show up in the guest with -serial unix:/tmp/com1,server,nowait I checked in the Device Manager with "Show hidden devices" enabled. Anyway, when starting the original problematic VM again, it now also got stuck (visually, in the same place) with QEMU 6.2.0! But only until I rebooted my host, which made it working with QEMU 6.2.0 again. So I'd say this commit has nothing to do with the issue after all, just made it more likely to trigger for me. And also seems less likely to be a QEMU issue now :) Best Regards, Fiona
