1 files changed, 44 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/771 b/results/classifier/118/graphic/771
new file mode 100644
index 000000000..f28a0fe28
--- /dev/null
+++ b/results/classifier/118/graphic/771
@@ -0,0 +1,44 @@
+graphic: 0.833
+performance: 0.746
+boot: 0.742
+device: 0.709
+ppc: 0.426
+architecture: 0.416
+socket: 0.376
+user-level: 0.367
+semantic: 0.362
+peripherals: 0.360
+mistranslation: 0.342
+register: 0.338
+vnc: 0.319
+PID: 0.305
+debug: 0.278
+hypervisor: 0.265
+i386: 0.257
+risc-v: 0.254
+x86: 0.253
+kernel: 0.240
+assembly: 0.192
+arm: 0.165
+VMM: 0.160
+permissions: 0.144
+KVM: 0.131
+virtual: 0.103
+TCG: 0.101
+network: 0.064
+files: 0.063
+
+No interrupts are delivered to the guest after rebooting Windows 98
+Description of problem:
+After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts.  The guest performs fine before the reboot.
+
+Closer examination reveals that no hardware interrupts are delivered to the guest.  BIOS Data Area variables like the keyboard buffer and the system clock are not updated.  Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor.
+
+The only remedy seems to be to exit the QEMU process entirely and launch it again.
+Steps to reproduce:
+0. Install Windows 98 into the guest.  (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.)
+1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load.  (I managed sometimes to reproduce the bug without the system having loaded fully.)
+2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent)
+3. Observe the system freeze.
+Additional information:
+None