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 ) 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.]