diff options
Diffstat (limited to 'results/classifier/108/other/1423528')
| -rw-r--r-- | results/classifier/108/other/1423528 | 48 |
1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/108/other/1423528 b/results/classifier/108/other/1423528 new file mode 100644 index 000000000..96aa094bf --- /dev/null +++ b/results/classifier/108/other/1423528 @@ -0,0 +1,48 @@ +device: 0.801 +graphic: 0.517 +semantic: 0.501 +PID: 0.439 +performance: 0.350 +other: 0.349 +KVM: 0.324 +network: 0.313 +boot: 0.239 +permissions: 0.232 +socket: 0.217 +debug: 0.151 +files: 0.135 +vnc: 0.120 + + 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 + + |