blob: 15235e6075b2b74a0f8fc6830300758df3b3c746 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
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
|