I found a fix!
I looked a little more carefully at the bug report you referenced and
saw something about updated virtio drivers so I downloaded and mounted
virtio-win-0.1.262.iso as a CD on the Windows VM, fired it up, installed
virtio-win-x64.msi and virio-win-guest-tools.exe, closed Windows, set
the Video to QXL, restarted Windows, and voilà, it works just fine. So
the problem isn't with QEMU but with out-of-date or overwritten Windows
drivers. You can close this bug now.
Thanks for all your help with this. Maybe another time we'll get to
bisect a git repo together...
Best,
Hank
On 10/7/24 16:39, Michael Tokarev wrote:
07.10.2024 23:24, Hank Knox wrote:
On 10/7/24 03:29, Michael Tokarev wrote:
The highlights:
-machine pc-q35-8.1
-cpu host -- what is your CPU anyway?
It's an AMD Ryzen 7 7840U w/ Radeon 780M Graphics. The machine is a
13' Framework, I've had it for a year, running Debian testing without
many issues.
It's actually quite close to my system, which has
AMD Ryzen 7 5700G with Radeon Graphics.
-smp 8
- ahci (sata) drive
- qxl
- e1000 nic
- intel hda audio
- sandbox
Still, I can't reproduce this behavior here, no matter how I try.
My VMs Just Work (tm).
I'm jealous...
I upgraded again to 9.1.0+ds-8, changed the video setting from QXL to
Virtio and fired up Windows. I ran it for over half an hour with no
freeze up, so it's something to do with the QXL video display. Does
this give you any ideas?
Not yet.. but there are other reports about QXL not working correctly in
windows, lemme find one.. for example, this one:
https://gitlab.com/qemu-project/qemu/-/issues/1628 - which says
there's an
error decoding graphics stream in a way so windows and qemu becomes
out of
sync. Unfortunately it received no attention, I come across it just
today
while researching this your issue. The bug mentioned there seems real.
I pinged the Windows VM after the display froze (using Video QXL) and
it actually responds. I got the IP address from 'virsh domifaddr
Windows10', I assume that's the right one to ping.
Hopefully yes, and it's rather interesting that your windows VM has ping
enabled. So you probably can log in to it remotely using rdp, from, say
a freerdp client, after enabling remote desktop in windows. That would
be interesting.
This is what I was trying to find out - is it whole windows kernel who
frozen, or qemu, or just display. With the above details it looks like
it is the display (and yes, I used qxl in my testing too, and it is the
most often used display anyway - it works fine). Maybe it also driver-
dependent, but qxl drivers hasn't updated for a few years (since 2020
iirc).
Or maybe I should use qxl with stdvga windows driver.
..
I don't think I ever saw any of the cores spinning up to 100% use
during the freeze up; it's frozen now (using QXL Video device) and
there is hardly any CPU activity in the guest or the host and the
guest usage is flat. While frozen, 'virsh domstate Windows10' says
'running'; I tried several 'virsh domXXX' commands and they all
returned something indicating activity behind the UI freeze.
Ok, that's excellent.
So we're with the qxl thing here (hopefully anyway - I still do have some
doubts about it), which I can't reproduce. I'm not sure what to do here.
Either I need a way to reproduce it locally, or you have to learn how to
do some git, compiling and bisecting, and quite some time to experiment
since the prob doesn't happen in a deterministic way. The
compiling/bisecting
isn't difficult but it requires a (relatively minor) setup first.
Or you can just switch to another vga type and be done with this :)
If you'll choose to help debugging/bisecting, it's better to have some
online
chat - over IRC or in a messenger - than to use bugtracker. I'm mjt
on freenode
and mjt0k on libera, if you're about irc.
Thanks,
/mjt
--
Hank Knox, FRSC
Schulich School of Music of
McGill University (retired)
Montreal, QC
