1 files changed, 61 insertions, 0 deletions
diff --git a/results/classifier/118/none/2961 b/results/classifier/118/none/2961
new file mode 100644
index 000000000..e53525894
--- /dev/null
+++ b/results/classifier/118/none/2961
@@ -0,0 +1,61 @@
+debug: 0.766
+architecture: 0.742
+boot: 0.674
+performance: 0.606
+semantic: 0.583
+device: 0.547
+hypervisor: 0.513
+ppc: 0.506
+user-level: 0.458
+socket: 0.391
+register: 0.377
+peripherals: 0.358
+permissions: 0.353
+x86: 0.337
+graphic: 0.331
+PID: 0.327
+risc-v: 0.317
+kernel: 0.316
+i386: 0.312
+files: 0.258
+TCG: 0.243
+vnc: 0.229
+mistranslation: 0.207
+assembly: 0.192
+VMM: 0.192
+virtual: 0.188
+network: 0.180
+arm: 0.138
+KVM: 0.088
+
+isapc: RTC refactor caused regression in qemu>=8.2 (broke Xenix, maybe others)
+Description of problem:
+I've been playing a bit with retro UNIXes and wanted to try a Xenix install.
+
+There are several webpages giving hints for installing Xenix under old versions of QEMU.  The good news: most of the workarounds and tweaks they mention seem to be no longer needed.  Starting with a Homebrew-supplied qemu 10.0.0 on my laptop I was able to do a basic install _without_ having to tweak the floppy geometry or anything like that.
+
+The bad news: once the install was complete and I tried to reboot from the harddrive it hangs at the...
+```
+Boot
+:
+```
+...prompt.  It doesn't respond to any keystrokes at this point.  This prompt is printed by the second-stage loader (called `/boot` on the Xenix filesystem) which is a real-mode 8086 binary.
+
+To debug this further I moved to a more familiar Linux developer environment and found that the qemu that is stock with Debian 12.10 (7.2.15) did *not* exhibit the same problem!
+
+I manually bisected through the released versions and found that it definitely broke some time in the 8.2 release cycle: 8.1.5 worked, 8.2.0rc0 did not.  I then did a git checkout and started building qemu, using `git bisect` to find the guilty commit.
+
+Soon I came across 56b1f50e3c101bfe5f52bac73de0e88438de11bd from @shentey -- a change which moved connecting the RTC's ISA interrupt from `pc_basic_device_init()` down into `*_realize()` when a Southbridge is configured.  I was able to confirm that before this commit I could boot, but after it I could not.
+
+I verified using gdb that `pc_basic_device_init()` is being called but the functions that the initialization had moved to were not (or at least weren't called *yet*). So after this change this RTC irq wasn't being wired up, which apparently broke the second-stage Xenix loader.
+
+I then went back to git tip and found that reverting the 56b1f50e3c1 commit was enough to fix the problem there as well.
+
+I don't know enough about the qemu internals to judge whether the original change made sense.  Therefore, I won't claim that reverting it is the correct approach to fix the bug.  However, it did work for me.
+
+The Southbridge code has been reorged a little since 8.2 but the functional revert is still pretty straightfoward.  Here is the diff I used:
+[revert-56b1f50e3c1.patch](/uploads/573754b8af3d7ddb97d5f973cb0003db/revert-56b1f50e3c1.patch)
+Steps to reproduce:
+1. Install Xenix 2.3.4 from https://archive.org/details/sco-xenix-386-and-extras
+2. After some enjoyable floppy juggling, be amazed at how smoothly the install went
+3. Try to boot from the harddrive afterwards and weep