1 files changed, 45 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/graphic/2728 b/results/classifier/zero-shot/118/graphic/2728
new file mode 100644
index 000000000..5f00b25f8
--- /dev/null
+++ b/results/classifier/zero-shot/118/graphic/2728
@@ -0,0 +1,45 @@
+graphic: 0.876
+x86: 0.723
+virtual: 0.669
+device: 0.610
+VMM: 0.457
+performance: 0.383
+socket: 0.375
+semantic: 0.346
+boot: 0.287
+hypervisor: 0.273
+permissions: 0.257
+PID: 0.234
+register: 0.193
+architecture: 0.189
+risc-v: 0.176
+vnc: 0.163
+network: 0.160
+ppc: 0.151
+debug: 0.123
+mistranslation: 0.120
+assembly: 0.112
+arm: 0.093
+peripherals: 0.092
+files: 0.088
+i386: 0.071
+kernel: 0.057
+user-level: 0.055
+TCG: 0.051
+KVM: 0.020
+
+QEMU/Virt-Manager + QXL 4k Resolution + Win 10 and Win 11 Guest freeze
+Description of problem:
+I use two 4k displays in my VM with 150% display scaling. After a random amount of time the screen locks up. It can lock up before i can log in or it can wait a few minutes into using it before it stops responding. It still pings but is unresponsive via the display. I've tried several different builds of the guest drivers but that did not work, the only solution has been to revert to QEMU v9.0.2-1.
+Steps to reproduce:
+1.Create new x86 VM using QXl video, Install Windows 10 or Windows 11 and latest guest drivers from spice and fedora
+2.Open with virt viewer and resize both screens to 3840 x 2160 or use autosize 
+3.Set display scaling to 150%
+4.Lockup occurs at some point after that but not more than 5 minutes.
+Additional information:
+There seems to be a similar bug here:https://gitlab.com/qemu-project/qemu/-/issues/1628#note_214460662
+also a debian forum post here: https://forums.debian.net/viewtopic.php?t=160631
+QEMU v9.0.2-1 does not have this problem, eliminating the guest drivers as a culprit
+
+
+/label ~"kind::Bug"