add 18th iteration of classifier

1 files changed, 41 insertions, 0 deletions

diff --git a/results/classifier/118/none/2464 b/results/classifier/118/none/2464
new file mode 100644
index 000000000..4a7b203f3
--- /dev/null
+++ b/results/classifier/118/none/2464
@@ -0,0 +1,41 @@
+device: 0.784
+architecture: 0.784
+boot: 0.732
+virtual: 0.630
+vnc: 0.609
+ppc: 0.538
+performance: 0.534
+register: 0.529
+semantic: 0.518
+kernel: 0.507
+peripherals: 0.488
+socket: 0.485
+network: 0.461
+files: 0.427
+PID: 0.416
+x86: 0.380
+risc-v: 0.364
+VMM: 0.314
+hypervisor: 0.283
+permissions: 0.271
+TCG: 0.249
+debug: 0.236
+arm: 0.159
+graphic: 0.151
+assembly: 0.151
+KVM: 0.148
+i386: 0.128
+user-level: 0.119
+mistranslation: 0.083
+
+"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens
+Description of problem:
+The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log.
+Steps to reproduce:
+1. Download a Windows NT 3.5x/4.0 ISO.
+2. Create a disk image ≤2GB in size.
+3. Enter the command above.
+4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``)
+5. Launch the installer by running ``cd:\mips\setupldr``.
+Additional information:
+![exhibit A; shows the 0x0000007b bugcheck output](/uploads/389e7b5fe77e259c6f3b2a703945df73/Screenshot_from_2024-07-28_18-44-15.png)