2 files changed, 47 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kernel/2078 b/results/classifier/gemma3:12b/kernel/2078
new file mode 100644
index 00000000..5734ade0
--- /dev/null
+++ b/results/classifier/gemma3:12b/kernel/2078
@@ -0,0 +1,35 @@
+
+Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target
+Description of problem:
+I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests.  Certain arithmetic operation that will trap in the guest will crash Qemu.  First case encountered is below.
+Steps to reproduce:
+1. Compile and run the following program in the m68k guest:
+
+```
+virt68k:thorpej 3$ cat crash-qemu.c                                            
+#include <limits.h>
+#include <stdlib.h>
+
+int divisor = -1;
+
+int
+main(int argc, char *argv[])
+{
+
+	if (argc > 1)
+		divisor = atoi(argv[1]);
+
+	return INT_MIN / divisor;
+}
+virt68k:thorpej 4$ 
+```
+
+Another minimal case would be:
+
+```
+move.l #-2147483648,%d0
+move.l #-1,%d1
+divsl.l %d1,%d1:%d0
+```
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/kernel/2078790 b/results/classifier/gemma3:12b/kernel/2078790
new file mode 100644
index 00000000..50d40e2d
--- /dev/null
+++ b/results/classifier/gemma3:12b/kernel/2078790
@@ -0,0 +1,12 @@
+
+jammy qemu x86 int3: 0000 [#1] SMP NOPTI 
+
+jammy:linux-lowlatency-hwe-6.8 6.8.0-44.44.1~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996)
+
+
+Recently (2024.08.05), I have been seeing this issue with ADT:systemd:upstream-1/2 test in which kernel panics/prints a stack. I have seen this with jammy:linux-lowlatency-hwe-6.8 and jammy:linux-ibm-6.8. Stack trace is different everytime because kernel receives an interrupt, drop what it is doing, and crash when handling the interrupt.
+
+I think this is an issue with qemu and not kernel. For jammy, we are using qemu 6.2 and there are some fixes related to x86 interrupt handling in 8.x (https://<email address hidden>/T/). I propose we create a launchpad bug and trace the issue. If I am correct, we shouldn't see this in noble. And we should occasionally see this in 5.15 jammy kernels (and more frequently with lowlantecy kernels).
+
+
+Meanwhile see comments below for some stack traces;
\ No newline at end of file