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
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
graphic: 0.947
mistranslation: 0.943
semantic: 0.939
device: 0.938
assembly: 0.933
instruction: 0.926
KVM: 0.925
socket: 0.925
other: 0.918
vnc: 0.916
network: 0.913
boot: 0.889
kvm hangs occasionally when switching out of the qemu console
To recreate (although this does *NOT* fail most of the time alas):
1) press "ctrl-alt-2" to switch to the qemu console.
2) type say "sendkey ctrl-alt-f1"
3) press "ctrl-alt-1".
Expected outcome: Switch to tty1 in the VM.
Actual outcome: No switch to tty1 in the VM. and qemu console unresponsive to any keyboard input.
Rather a vague problem description I'm afraid but this has happened to me 3 times recently. No crash and no excessive CPU is observed.
I'll grab an strace when it happens again and attach...
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: qemu-system-x86 1.6.0+dfsg-2ubuntu4
ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1
Uname: Linux 3.12.0-4-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.12.7-0ubuntu1
Architecture: i386
CurrentDesktop: Unity
Date: Tue Dec 3 15:41:40 2013
InstallationDate: Installed on 2010-10-21 (1139 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
SourcePackage: qemu
UpgradeStatus: Upgraded to trusty on 2013-11-01 (31 days ago)
... as if by magic it hung again :) I managed to trigger it by toggling the following two key combos rapidly starting from within the qemu console:
ctrl-alt-1 # switch to console (actually, we're already there, but ...)
ctrl-alt-2 # switch out of console
Is this new to this version?
Can you reproduce it with either saucy's kvm, or with the previous
version published in trusty?
I never saw the issue with saucy. Downgrading to 1.5.0+dfsg-3ubuntu5.1 certainly appears to have resolved the issue for me, so it's looking like a regression introduced by 1.6.0+dfsg-2ubuntu4.
Thanks, James. I suspect this is due to the arm64-user-static patchset i added. As mjt has pointed out it has a lot of cruft in it. I'll have to drop it and try to come up with a smaller patchset.
Hi,
1.7 is currently building trusty. Could you please test with it and make sure that this bug is fixed with that version?
Hi Serge,
1.7.0+dfsg-2ubuntu2 still exhibits the problem I'm afraid.
That's surprising. Can you test it with upstream qemu?
(
git clone git://git.qemu.org/qemu.git
cd qemu
./configure --target-list=x86_64-softmmu
make
cd x86_64-softmmu
./qemu-system-x86_64 --enable-kvm <qemu-args>
)
Hi Serge,
Yes, I get the hang on upstream too (HEAD e157b8fdd412d48eacfbb8c67d3d58780154faa3).
Thanks, James. I'll aim to test on some older releases and bisect if possible.
If you have a chance to test on precise, raring, and saucy, or to actually bisect in the upstream git tree, please let me know.
Hi James,
just a quick check - do you get this with the qemu package in ppa:ubuntu-virt/candidate?
HI Serge - yes, problem is still there with the ppa versions:
$ dpkg -l|egrep "kvm|qemu"
ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1 all PXE boot firmware - ROM images for qemu
ii kvm-ipxe 1.0.0+git-20131111.c3d1e78-2ubuntu1 all transitional dummy package
ii kvm-pxe 5.4.5 all Meta package providing kvm pxe-boot ROMs.
ii qemu-common 2.0~git-20140320.71461b0-0ubuntu1 all dummy transitional package from qemu-common to qemu-keymaps
ii qemu-keymaps 2.0~git-20140320.71461b0-0ubuntu1 all QEMU keyboard maps
ii qemu-kvm 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU Full virtualization on x86 hardware (transitional package)
ii qemu-kvm-extras-static 1.2.0-2012.09-0ubuntu2 all QEMU static user mode emulation binaries (transitional package)
ii qemu-system 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries
ii qemu-system-arm 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (arm)
ii qemu-system-common 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU full system emulation binaries (common files)
ii qemu-system-mips 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (mips)
ii qemu-system-misc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (miscelaneous)
ii qemu-system-ppc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (ppc)
ii qemu-system-sparc 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (sparc)
ii qemu-system-x86 1.7.0+dfsg-3ubuntu7 i386 QEMU full system emulation binaries (x86)
ii qemu-user-static 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU user mode emulation binaries (static version)
ii qemu-utils 2.0~git-20140320.71461b0-0ubuntu1 i386 QEMU utilities
That is an odd looking list - why is qemu-system-x86 still on 1.7.0, while qemu-system-common is on 2.0?
Sorry - ignore that. However, problem persists on a separate fully-updated amd64 trusty system running kvm version 2.0.0~rc1+dfsg-0ubuntu3.
I've been trying to reproduce with current trusty, but on amd64, with no success.
Which guest were you using? Can you reproduce it just booting a desktop iso with SDL graphics, i.e.
kvm -cdrom ubuntu-13.10-desktop-$arch.iso -m 512
?
(Will test on i386. If that succeeds then I can bisect.)
Hi Serge,
I'm running on pure amd64 too so the problem is not arch-specific.
The simplest way to recreate:
$ kvm -cdrom /usr/lib/memtest86+/memtest86+.iso -m 512
Just hold down control+alt and frantically toggle the monitor using the '2' and '1'. Within a couple of seconds it hangs.
Sadly a bisect pointed to the unlikely commit 7a239e46.
Upstream git head is still affected.
Maddeningly, I've not yet been able to reproduce this by doing
for i in `seq 1 100`; do
xdotool search --name qemu keydown ctrl+alt+2
xdotool search --name qemu keyup ctrl+alt+2
xdotool search --name qemu keydown ctrl+alt+1
xdotool search --name qemu keyup ctrl+alt+1
done
A-ha, the reason is that this only triggers if the qemu window is focused. Running the script while focusing does reproduce (and do other weird things).
So perhaps this is happening in sdl_grab_start(), which exits early if the app is not focused?
Interestingly, after i lock the qemu console up with the xdo script,
the screen is always locked in ctrl-alt-2, that is, the monitor, not the vm display,
hitting ctrl-alt-1 never returns it to the vm display,
but if i continue the xdo script running, it sometimes does return to the vm display, where you can see memtest continuing to run.
So it appears that what is locking up is the display of the monitor.
Can you still reproduce this issue with the latest version of QEMU, or could we close this ticket nowadays?
Still happened in qemu 2.5.0 on Ubuntu 16.04, it's random but you can only switch between console, monitor, serial, parallel several times, then it hangs.
It seems the issue is sdl related to change in sdl window size. If I started qemu and set the monitor (and serial & parallel) to the same VC size, it works much better. Instead of hangs on a 2-3 switches, it may hang after rapid switch of more than 10 times. Btw, it can hang in any windows, i.e. display, monitor or serial/parallel.
So the workaround to ease this is, something like '-monitor vc:640x480 -serial vc:640x480'.
Could you please check with the latest version of QEMU (v2.12), and make sure that you're using SDL2 instead of SDL1.2 (since the latter is going to be removed soon)?
[Expired for QEMU because there has been no activity for 60 days.]
[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
|