Bug 1480775 - Assertion `mutex->initialized' failed in qxl_render_update
Summary: Assertion `mutex->initialized' failed in qxl_render_update
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 26
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-11 20:56 UTC by ademaria
Modified: 2017-08-25 21:48 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-25 21:48:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Stacktrace (8.61 KB, text/plain)
2017-08-13 15:08 UTC, ademaria
no flags Details
Stacktrace with backtrace output (12.25 KB, text/plain)
2017-08-13 15:24 UTC, ademaria
no flags Details

Description ademaria 2017-08-11 20:56:36 UTC
Description of problem:
Can no longer run qemu on F26. The same qemu command worked fine on F23.

I am currently getting a seg fault with the following output:

$ sudo ./command.sh 
Running  qemu-system-x86_64  -cpu host -m 6144 -vga qxl -device qxl -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 -enable-kvm -smp 8,sockets=1,cores=4,threads=2 -drive  file=/mnt/VM_Images/win10_cdrive.raw.bak,if=virtio,index=1 -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd -drive if=pflash,format=raw,file=/mnt/VM_Images/win10_ovmf_vars_x64.bin.bak -net nic,vlan=0,model=virtio -net bridge,vlan=0,br=brmain -rtc base=localtime

** (qemu-system-x86_64:2562): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-LkU8sIZDue: Connection refused
qemu-system-x86_64: -net nic,vlan=0,model=virtio: 'vlan' is deprecated. Please use 'netdev' instead.
WARNING: Image format was not specified for '/mnt/VM_Images/win10_cdrive.raw.bak' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-x86_64: /builddir/build/BUILD/qemu-2.10.0-rc1/util/qemu-thread-posix.c:64: qemu_mutex_lock: Assertion `mutex->initialized' failed.
./command.sh: line 60:  2562 Aborted                 (core dumped) $ENV qemu-system-x86_64 $OPTS


Version-Release number of selected component (if applicable):
I have enabled the fedora virt preview repo:

$ sudo dnf list installed | grep qemu | head -n 4
                                                            @qemu-firmware-jenkins
ipxe-roms-qemu.noarch               20161108-4.gitb991c67.fc26
libvirt-daemon-driver-qemu.x86_64   3.6.0-1.fc26            @fedora-virt-preview
qemu.x86_64                         2:2.10.0-0.1.rc1.fc26   @fedora-virt-preview


How reproducible:
consistent

Steps to Reproduce:
1. 
2.
3.

Actual results:
Seg fault and command terminated

Expected results:
A windows host running

Additional info:

Comment 1 Richard W.M. Jones 2017-08-12 08:05:09 UTC
Can you grab a stack trace from the core dump?  Knowing that the
error occurs in qemu-thread-posix.c is not very helpful since that's
simply a set of wrappers around the pthread functions.

Comment 2 ademaria 2017-08-13 15:08:27 UTC
Created attachment 1312731 [details]
Stacktrace

Comment 3 Richard W.M. Jones 2017-08-13 15:15:57 UTC
Something in QXL then ...

                #3  0x00007f86572e5da2 __GI___assert_fail (libc.so.6)
                #4  0x0000556c1cca2a65 qemu_mutex_lock (qemu-system-x86_64)
                #5  0x0000556c1cae1ea8 qxl_render_update (qemu-system-x86_64)
                #6  0x0000556c1cbb8f82 dpy_refresh (qemu-system-x86_64)
                #7  0x0000556c1cc9f8f0 timerlist_run_timers (qemu-system-x86_64)
                #8  0x0000556c1cc9faf7 qemu_clock_run_timers (qemu-system-x86_64)
                #9  0x0000556c1cc9ffda main_loop_wait (qemu-system-x86_64)
                #10 0x0000556c1c911bef main (qemu-system-x86_64)
                #11 0x00007f86572d74da __libc_start_main (libc.so.6)
                #12 0x0000556c1c914afa _start (qemu-system-x86_64)

Comment 4 ademaria 2017-08-13 15:24:34 UTC
Created attachment 1312744 [details]
Stacktrace with backtrace output

Comment 5 Cole Robinson 2017-08-14 13:12:05 UTC
(In reply to Richard W.M. Jones from comment #3)
> Something in QXL then ...
> 
>                 #3  0x00007f86572e5da2 __GI___assert_fail (libc.so.6)
>                 #4  0x0000556c1cca2a65 qemu_mutex_lock (qemu-system-x86_64)
>                 #5  0x0000556c1cae1ea8 qxl_render_update (qemu-system-x86_64)
>                 #6  0x0000556c1cbb8f82 dpy_refresh (qemu-system-x86_64)
>                 #7  0x0000556c1cc9f8f0 timerlist_run_timers
> (qemu-system-x86_64)
>                 #8  0x0000556c1cc9faf7 qemu_clock_run_timers
> (qemu-system-x86_64)
>                 #9  0x0000556c1cc9ffda main_loop_wait (qemu-system-x86_64)
>                 #10 0x0000556c1c911bef main (qemu-system-x86_64)
>                 #11 0x00007f86572d74da __libc_start_main (libc.so.6)
>                 #12 0x0000556c1c914afa _start (qemu-system-x86_64)

Gerd, this is with qemu-2.10.0-rc1, seen any reports about this yet?

Comment 6 Paolo Bonzini 2017-08-14 23:17:07 UTC
Minimal reproducer:

    $ qemu-system-x86_64 -device qxl

ademaria, as a workaround are you sure you need both "-vga qxl" and "-device qxl"?

Comment 7 ademaria 2017-08-17 23:55:50 UTC
Ran an update pulling 2.10.0-0.2.rc3.fc26, and this particular bug is now resolved. Now running into a new issue where the guest doesn't start and the host hangs consuming a bunch of cpu time.

Comment 8 Cole Robinson 2017-08-25 21:48:20 UTC
Since this issue sounds like it's gone, closing this bug. ademaria please file a separate bug about the host hang, and provide your kernel version (and make sure you are running latest f26 kernel)


Note You need to log in before you can comment on or make changes to this bug.