Hide Forgot
Description of problem: qemu-kvm fails/hangs after running several applications on the Guest. I connect to the guest with using spicec. Qemu-kvm is started through cli: /usr/libexec/qemu-kvm -vga qxl -m 1024 -smp 2 -spice port=3001,disable-ticketing /dev/rootvm/RHEL61_x64_test. RHEL61_x64_test is lv with installed guest. After connect to the guest with using spicec (spicec --host localhost --port 3001) and starting several applications qemu-kvm hangs/fails with output: handle_dev_destroy_surfaces: red_wait_outgoing_item: blocked / handle_dev_destroy_surfaces: red_wait_outgoing_item: blocked qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/qemu-kvm.c:2574: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.147.el6.x86_64 Host: Linux 2.6.32-114.0.1.el6.x86_64 Guest: Linux 2.6.32-114.0.1.el6.x86_64 spice-client spice-client-0.7.3-1.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Run through cli qemu-kvm with installed guest (/usr/libexec/qemu-kvm -vga qxl -m 1024 -smp 2 -spice port=3001,disable-ticketing /dev/rootvm/RHEL61_x64_test) with spice options. 2. Connect to the guest using spicec. (spicec --host localhost --port 3001) 3. Keep starting different applications (FF, OOO, etc.) till qemu hangs/fails with output such as: handle_dev_destroy_surfaces: red_wait_outgoing_item: blocked handle_dev_destroy_surfaces: qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/qemu-kvm.c:2574: kvm_mutex_unlock: Assertion `!cpu_single_env' faileds: or handle_dev_destroy_surfaces: red_wait_outgoing_item: blocked. Additional info: Sometimes only session is logged out instead of failing/hanging.
From bt: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x0000003fe2e09345 in _L_lock_870 () from /lib64/libpthread.so.0 #2 0x0000003fe2e09217 in __pthread_mutex_lock (mutex=0x8e39a0) at pthread_mutex_lock.c:61 #3 0x000000000042af4e in kvm_mutex_lock () at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2580 #4 0x000000000040b8d8 in main_loop_wait (timeout=1000) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:4418 #5 0x000000000042b2fa in kvm_main_loop () at /usr/src/debug/qemu-kvm-0.12.1.2/qemu-kvm.c:2165 #6 0x000000000040ef0f in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:4634 #7 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/vl.c:6848
Seems like it happens only with -vga qxl set (guest driver doesn't matter) I got the same freeze with vesa and qxl.
I'm getting kicked off the session after like 20 seconds of usage.
This does happen also with single vcpu
Created attachment 480718 [details] multi-threaded backtrace Attached multi-threaded backtrace, qemu-kvm hanged right after start of guest's X. CL was: $ qemu-kvm -smp 2 -m 1024 -name rhel6_32 -enable-kvm -spice port=3001,disable-ticketing -soundhw ac97 -vga qxl /dev/root_vg/q-rhel6_32
From origin: > Additional info: > Sometimes only session is logged out instead of failing/hanging. reported as separate bug: https://bugzilla.redhat.com/show_bug.cgi?id=680120
I could not reproduce with a single vcpu and some applications running (did not try too hard). Easily reproduced the "hanging" part of the bug with "chvt 4" and trying to chvt back to the X console. It seems that the problem is missing mutex unlocks. We have a patch upstream (spice upstream not qemu) that fixes such issues; and specifically, the exact same issue that we've encountered -- in qxl_add_memslot. Upstream in (spice) patch: 4855161da1f6dbc129593487814cd8518016de20
(In reply to comment #9) > I could not reproduce with a single vcpu and some applications running (did not > try too hard). scratch that. Easily reproduced following the instructions in #comment0 ("Steps to Reproduce"), sometimes even before that when X starts. I guess I was just lucky earlier and I did not try too hard (used chvt instead of installing OOO).
This bug looks like a duplicate of 678208 to me, especially when looking at the stack trace (comment#2). *** This bug has been marked as a duplicate of bug 678208 ***