add 18th iteration of classifier

1 files changed, 43 insertions, 0 deletions

diff --git a/results/classifier/118/kernel/1157 b/results/classifier/118/kernel/1157
new file mode 100644
index 000000000..0c39a89c4
--- /dev/null
+++ b/results/classifier/118/kernel/1157
@@ -0,0 +1,43 @@
+architecture: 0.980
+kernel: 0.934
+register: 0.897
+graphic: 0.879
+device: 0.812
+debug: 0.800
+arm: 0.774
+semantic: 0.725
+permissions: 0.549
+performance: 0.518
+peripherals: 0.501
+files: 0.493
+vnc: 0.492
+network: 0.465
+PID: 0.453
+socket: 0.434
+boot: 0.432
+ppc: 0.401
+assembly: 0.334
+user-level: 0.317
+risc-v: 0.316
+TCG: 0.294
+hypervisor: 0.266
+VMM: 0.216
+i386: 0.134
+KVM: 0.133
+virtual: 0.093
+x86: 0.085
+mistranslation: 0.045
+
+aarch64: enabling MMU causes instruction abort
+Description of problem:
+The title describes the problem pretty accurately, we get an instruction abort when enabling the MMU with a pretty simple set of page tables. This has been regressed from qemu 6.x.
+Steps to reproduce:
+1. Run the provided Kernel binary with the command line specified above.
+2. Notice the hang after 'Initialize MMU'. I traced it down to being an instructions abort after the write to the SCTLR_EL1 register.
+3. Try to run with qemu 6.x, and notice that it works.
+Additional information:
+This does work on actual hardware, so it has to be a qemu bug.
+
+A binary of the Serenity Kernel has been attached to the issue. The source of that binary can be found at commit ca0e32e59fcf67a662e5d3a994d44cd7c941624a of [SerenityOS](https://github.com/SerenityOS/serenity).
+
+[Kernel](/uploads/f731edbf81d8e575035e9693b0a51dbf/Kernel)