1 files changed, 44 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/2897 b/results/classifier/118/graphic/2897
new file mode 100644
index 000000000..aea99c2f1
--- /dev/null
+++ b/results/classifier/118/graphic/2897
@@ -0,0 +1,44 @@
+graphic: 0.966
+boot: 0.904
+device: 0.847
+x86: 0.713
+architecture: 0.681
+performance: 0.677
+vnc: 0.667
+semantic: 0.640
+hypervisor: 0.551
+debug: 0.543
+virtual: 0.534
+network: 0.497
+user-level: 0.458
+PID: 0.430
+i386: 0.408
+VMM: 0.398
+register: 0.353
+risc-v: 0.338
+mistranslation: 0.319
+arm: 0.295
+permissions: 0.261
+socket: 0.232
+TCG: 0.226
+ppc: 0.224
+files: 0.216
+peripherals: 0.194
+KVM: 0.171
+kernel: 0.138
+assembly: 0.118
+
+Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl
+Description of problem:
+When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot.
+Steps to reproduce:
+1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST.
+2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST.
+Additional information:
+This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. 
+
+I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction.
+
+There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk`
+
+#