summary refs log tree commit diff stats
path: root/results/classifier/105/device/1423528
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/105/device/1423528')
-rw-r--r--results/classifier/105/device/142352846
1 files changed, 46 insertions, 0 deletions
diff --git a/results/classifier/105/device/1423528 b/results/classifier/105/device/1423528
new file mode 100644
index 000000000..8a9ea2be7
--- /dev/null
+++ b/results/classifier/105/device/1423528
@@ -0,0 +1,46 @@
+device: 0.801
+graphic: 0.517
+semantic: 0.501
+instruction: 0.475
+other: 0.349
+KVM: 0.324
+network: 0.313
+mistranslation: 0.260
+boot: 0.239
+socket: 0.217
+vnc: 0.120
+assembly: 0.076
+
+ 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
+
+