summary refs log tree commit diff stats
path: root/gitlab/issues_text/target_i386/host_missing/accel_missing/771
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-01 21:35:14 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-06-01 21:35:14 +0200
commit3e4c5a6261770bced301b5e74233e7866166ea5b (patch)
tree9379fddaba693ef8a045da06efee8529baa5f6f4 /gitlab/issues_text/target_i386/host_missing/accel_missing/771
parente5634e2806195bee44407853c4bf8776f7abfa4f (diff)
downloadqemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.tar.gz
qemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.zip
clean up repository
Diffstat (limited to 'gitlab/issues_text/target_i386/host_missing/accel_missing/771')
-rw-r--r--gitlab/issues_text/target_i386/host_missing/accel_missing/77114
1 files changed, 0 insertions, 14 deletions
diff --git a/gitlab/issues_text/target_i386/host_missing/accel_missing/771 b/gitlab/issues_text/target_i386/host_missing/accel_missing/771
deleted file mode 100644
index 9a8fb2117..000000000
--- a/gitlab/issues_text/target_i386/host_missing/accel_missing/771
+++ /dev/null
@@ -1,14 +0,0 @@
-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