1 files changed, 63 insertions, 0 deletions
diff --git a/results/classifier/118/x86/1423528 b/results/classifier/118/x86/1423528
new file mode 100644
index 000000000..15235e607
--- /dev/null
+++ b/results/classifier/118/x86/1423528
@@ -0,0 +1,63 @@
+x86: 0.843
+device: 0.801
+architecture: 0.529
+graphic: 0.517
+semantic: 0.501
+PID: 0.439
+performance: 0.350
+KVM: 0.324
+i386: 0.316
+network: 0.313
+user-level: 0.288
+peripherals: 0.275
+register: 0.266
+mistranslation: 0.260
+boot: 0.239
+permissions: 0.232
+socket: 0.217
+ppc: 0.199
+hypervisor: 0.198
+virtual: 0.159
+debug: 0.151
+kernel: 0.137
+files: 0.135
+arm: 0.131
+vnc: 0.120
+risc-v: 0.099
+TCG: 0.082
+assembly: 0.076
+VMM: 0.066
+
+ setting unsupported timeout for i6300esb watchdog causes hw reset
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778291
+Version: 2.1
+
+systemd utilizes existing watchdog hardware and set's a 10min timer on reboot.
+The i6300esb under qemu doesn't like such a timeout, and immediately resets the hardware:
+
+The last message one gets is
+[    9.402243] i6300esb: Unexpected close, not stopping watchdog!
+
+
+The linked bug report contains information how this bug can easily be reproduced.
+With any image using a recent enough systemd as PID 1 you should be able to reproduce it by running
+
+qemu-system-x86_64 -curses -enable-kvm -device i6300esb -watchdog-action reset -hda <image with systemd>
+
+
+I'm uncertain if this is a qemu or kernel/driver bug. If the latter, please re-assign the bug as necessary.
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+There's nothing changed in i6300esb about this issue. I can reproduce it exactly the same way with current qemu 5.1-tobe
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/112
+
+