kvm hangs occasionally when switching out of the qemu console

[James Hunt]

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)

[James Hunt (jamesodhunt)]

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

[Serge Hallyn (serge-hallyn)]

Is this new to this version?

Can you reproduce it with either saucy's kvm, or with the previous
version published in trusty?

[James Hunt (jamesodhunt)]

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.

[Serge Hallyn (serge-hallyn)]

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.

[Serge Hallyn (serge-hallyn)]

Hi,

1.7 is currently building trusty. Could you please test with it and make sure that this bug is fixed with that version?

[James Hunt (jamesodhunt)]

Hi Serge,

1.7.0+dfsg-2ubuntu2 still exhibits the problem I'm afraid.

[Serge Hallyn (serge-hallyn)]

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

[James Hunt (jamesodhunt)]

Hi Serge,

Yes, I get the hang on upstream too (HEAD e157b8fdd412d48eacfbb8c67d3d58780154faa3).

[Serge Hallyn (serge-hallyn)]

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.

[Serge Hallyn (serge-hallyn)]

Hi James,

just a quick check - do you get this with the qemu package in ppa:ubuntu-virt/candidate?

[James Hunt (jamesodhunt)]

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

[Serge Hallyn (serge-hallyn)]

That is an odd looking list - why is qemu-system-x86 still on 1.7.0, while qemu-system-common is on 2.0?

[James Hunt (jamesodhunt)]

Sorry - ignore that. However, problem persists on a separate fully-updated amd64 trusty system running kvm version 2.0.0~rc1+dfsg-0ubuntu3.

[Serge Hallyn (serge-hallyn)]

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

[James Hunt (jamesodhunt)]

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.

[Serge Hallyn (serge-hallyn)]

Sadly a bisect pointed to the unlikely commit 7a239e46.

Upstream git head is still affected.

[Serge Hallyn (serge-hallyn)]

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

[Serge Hallyn (serge-hallyn)]

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?

[Serge Hallyn (serge-hallyn)]

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.

[Thomas Huth (th-huth)]

Can you still reproduce this issue with the latest version of QEMU, or could we close this ticket nowadays?

[Edoardo Tirtarahardja (etirta)]

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.

[Edoardo Tirtarahardja (etirta)]

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'.

[Thomas Huth (th-huth)]

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)?

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]