[Qemu-devel] After patch to fix non repeating keys, keys get stuck on Windows guests
Using QEMU version 3.1.50 (v3.1.0-2338-g1ba530a4ec-dirty), after the commit 35921860156e39f17ffd7e18d0f84d2396a6e8f4 kbd-state: don't block auto-repeat events It was noticed that keys can get stuck on an Intel GVT-g (iGVT-g) Windows 10 guest. For example, pressing "e" will result on "ee" until the key "e" is pressed again. I tried to reproduce this on simple Linux guests and simple Windows 10 guests but failed to do so. The QEMU command line is pretty long: sudo env QEMU_AUDIO_DRV=pa QEMU_AUDIO_DAC_FIXED_FREQ=96000 QEMU_AUDIO_ADC_FIXED_FREQ=96000 QEMU_PA_SERVER=/run/user/1000/pulse/native QEMU_AUDIO_ADC_VOICES=0 PULSE_LATENCY_MSEC=10 qemu-system-x86_64 -name 'Windows 10' -k pt-br -nodefaults -device nec-usb-xhci,id=necxhci -hda /home/usuario/.local/share/libvirt/images/redm.qcow2 -enable-kvm -cpu Skylake-Client,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_runtime -smp cores=2,threads=2 -m 3072M -bios /usr/local/share/qemu/bios.bin -device usb-tablet,id=tablet -device usb-audio,id=usbaudvir,buffer=6144 -device usb-host,vendorid=0x0079,id=redragon -device usb-host,vendorid=0x0458,id=mousegenius -vga none -monitor vc -serial stdio -display gtk,gl=on -device vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/123f09b0-4c00-11e8-a6ca-f3c21e47e012,x-igd-opregion=on,rombar=0,display=on,addr=0x3,id=iHD520 -machine kernel_irqchip=on -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -M pc,usb=false -netdev user,id=net0 -device e1000,netdev=net0,id=n0,addr=0x8 -device usb-host,vendorid=0x0480,productid=0x0200,id=toshiba "redragon" is a gamepad, "toshiba" an external HDD and "mousegenius" is a mouse. The problem was noticed both with devices connected and disconnected, and when they were removed using device_del. While I faced this on multiple situations (even using notepad, for example), this bug is easy to trigger with games. It seems the usb-audio emulation plus iGVT-g load plus high CPU load makes the key release event never to be sent to the guest, making the key get stuck on the guest until it is pressed again.
[Qemu-devel] Key repeat is no longer working on TTY and grub menu
I noticed that the key inputs are no longer repeating when using default setting on QEMU. For example, if I press "a" and keep it pressed it will print only one "a" instead of repeating them. Another example is when deleting text: instead of holding backspace pressed and the text is deleted, it's needed to press backspace once for each character. As this makes many tasks much slower, requiring many key presses for tasks that were done in a single press, I did a bisect to see when this change happened. The result is: 0c0d42737dfdcea872a987ecba6ef55047df8881 is the first bad commit commit 0c0d42737dfdcea872a987ecba6ef55047df8881 Author: Gerd Hoffmann Date: Tue Jan 22 10:28:11 2019 +0100 kbd-state: use state tracker for gtk Use the new keyboard state tracked for gtk. Allows to drop the gtk-specific modifier state tracking code. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel P. Berrangé Message-id: 20190122092814.14919-6-kra...@redhat.com :04 04 e882f144bafca90257a4604b5e62486a1ca038b2 0139afe1aee24256c3f711c080b0230ab104074a M include :04 04 c258efc06107b944b0627792b9f2377600033118 4fd01a25a3e0d1fccca72c35ec58b205aa4fd882 M ui I'm using the GTK interface and all guests without a Graphical User Interface (GUI) are affected by this. This happens on grub menu and on TTY of multiple Linux guests. Workarounds found for the key repeat issue: -Installing a GUI to server systems; -Adding a usb-kbd device, but then the key '/' is lost.
Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga
Thank you for testing this, the last update greatly improved the situation. libspice-server1 updated, so I rebuilt QEMU. The libspice-server1 0.14.0-1ubuntu2.4 change log is: * SECURITY UPDATE: off-by-one error in memslot_get_virt - debian/patches/CVE-2019-3813.patch: fix checks in server/memslot.c, add tests to server/tests/test-qxl-parsing.c. - CVE-2019-3813 * debian/tests/automated-tests: fix incorrect test name, don't fail on build writing to stderr. The errors on terminal are: (qemu:11683): Spice-CRITICAL **: 18:39:40.747: memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff00ff00 Abortado (imagem do núcleo gravada) The function that was changed with the last update seems to be the exact same function that was causing the crash. Now the crash happens ONLY in the first execution. All subsequent executions work correctly. While the guest crashes on the first execution, it seems the guest file system is resilient enough to suffer no damages from the crash on the first boot and subsequent boots all seem perfect. I installed the debug symbols for libglib-2.0 too, hopefully the additional debug messages have some useful information. From the first execution that crashes (gtk,gl=on and gtk had the same result): qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048 -hda neonbroken.qcow2 -device qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd id 0, group 0, virt start 0, virt end , generation 0, delta 0 id 1, group 1, virt start 7fff1fe0, virt end 7fff23dfe000, generation 0, delta 7fff1fe0 id 2, group 1, virt start 7fff1bc0, virt end 7fff1fc0, generation 0, delta 7fff1bc0 (qemu:1937): Spice-CRITICAL **: 20:17:21.623: memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff00ff00 (gdb) bt #0 0x70371e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x70373801 in __GI_abort () at abort.c:79 #2 0x7116fcc9 in spice_logv (log_domain=0x711da9f5 "Spice", args=0x7fff36028cb0, format=0x711e1c5b "slot_id %d too big, addr=%lx", function=0x711e1d90 <__FUNCTION__.15594> "memslot_get_virt", strloc=0x711e1c78 "memslot.c:111", log_level=G_LOG_LEVEL_CRITICAL) at log.c:183 #3 0x7116fcc9 in spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x711e1c78 "memslot.c:111", function=function@entry=0x711e1d90 <__FUNCTION__.15594> "memslot_get_virt", format=format@entry=0x711e1c5b "slot_id %d too big, addr=%lx") at log.c:196 #4 0x711353b8 in memslot_get_virt (info=info@entry=0x579bce10, addr=addr@entry=18374686483949813760, add_size=add_size@entry=10, group_id=group_id@entry=1, error=error@entry=0x7fff36028e08) at memslot.c:111 #5 0x7113e7d0 in red_get_image (slots=slots@entry=0x579bce10, group_id=group_id@entry=1, addr=, flags=flags@entry=0, is_mask=is_mask@entry=false) at red-parse-qxl.c:512 #6 0x7113ea76 in red_get_copy_ptr (slots=slots@entry=0x579bce10, group_id=group_id@entry=1, red=red@entry=0x7fff1409f330, qxl=0x7fff1fe0107b, flags=flags@entry=0) at red-parse-qxl.c:680 #7 0x7113f9a1 in red_get_native_drawable (flags=, addr=, red=, group_id=, slots=) at red-parse-qxl.c:1072 #8 0x7113f9a1 in red_get_drawable (slots=slots@entry=0x579bce10, group_id=1, red=red@entry=0x7fff1409f290, addr=, flags=0) at red-parse-qxl.c:1206 #9 0x711523cd in red_process_display (worker=0x579bcd80, ring_is_empty=0x7fff36028f9c) at red-worker.c:224 #10 0x71150d21 in flush_commands (worker=worker@entry=0x579bcd80, red_channel=0x579b9210 [DisplayChannel], process=process@entry=0x71152220 ) at red-worker.c:315 #11 0x71150e58 in flush_display_commands (worker=worker@entry=0x579bcd80) at red-worker.c:352 #12 0x711514bf in flush_all_qxl_commands (worker=0x579bcd80) at red-worker.c:367 #13 0x711514bf in destroy_primary_surface (worker=0x579bcd80, surface_id=0) at red-worker.c:558 #14 0x7111f4f1 in dispatcher_handle_single_read (dispatcher=0x56a1d1c0 [Dispatcher]) at dispatcher.c:284 #15 0x7111f4f1 in dispatcher_handle_recv_read (dispatcher=0x56a1d1c0 [Dispatcher]) at dispatcher.c:304 #16 0x71125d7b in watch_func (source=, condition=, data=0x579bcf60) at event-loop.c:128 #17 0x747911f5 in g_main_dispatch (context=0x579bce70) at ../../../../glib/gmain.c:3176 #18 0x747911f5 in g_main_context_dispatch (context=context@entry=0x579bce70) at ../../../../glib/gmain.c:3829 #19 0x747915c0 in g_main_context_iterate (context=0x579bce70, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../../glib/gmain.c:3902 #20 0x747918d2 in g_main_loop_run (loop=0x7fff14002530) at
Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga
Mageia 7 guest is crashing too. The command line: qemu-system-x86_64 \ -name "Mageia 7" -k pt-br -nodefaults -accel kvm -cpu host -smp cores=2,threads=1 -m 1G \ -device qxl-vga,xres=1366,yres=768 \ -device qemu-xhci,id=xhcihub -device usb-audio,id=usbaudio,buffer=6144 \ -device usb-tablet,id=usbtablet -bios /usr/share/ovmf/OVMF.fd -display gtk,gl=on \ -drive if=virtio,file=mageia7.qcow2 \ -monitor vc -serial vc -cdrom "Mageia-7-beta1-Live-Xfce-x86_64.iso" \ -machine kernel_irqchip=on -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -M pc,usb=true \ -netdev user,id=net0 -device e1000,netdev=net0,addr=8 It seems that: -drive if=virtio,file= is the cause of this. Replacing it with -hda makes the Mageia 7 guest work normally. KDE Neon guest still crashes because of the other problem. (gdb) bt #0 0x70371e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x70373801 in __GI_abort () at abort.c:79 #2 0x5589eac9 in kvm_mem_ioeventfd_add (listener=0x56b4ffd8, section=0x7fffcdf23a90, match_data=false, data=0, e=0x57b51658) at /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866 #3 0x5588300a in address_space_add_del_ioeventfds (as=0x567e5a00 , fds_new=0x7fffc4560fc0, fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at /home/usuario/Documentos/qemu/memory.c:793 #4 0x558832f4 in address_space_update_ioeventfds (as=0x567e5a00 ) at /home/usuario/Documentos/qemu/memory.c:843 #5 0x5588415b in memory_region_transaction_commit () at /home/usuario/Documentos/qemu/memory.c:1094 #6 0x558871c8 in memory_region_add_eventfd (mr=0x57b3fa00, addr=0, size=0, match_data=false, data=0, e=0x57b51658) at /home/usuario/Documentos/qemu/memory.c:2303 #7 0x55c26cd0 in virtio_pci_ioeventfd_assign (d=0x57b3ed30, notifier=0x57b51658, n=0, assign=true) at hw/virtio/virtio-pci.c:243 #8 0x55c24dd5 in virtio_bus_set_host_notifier (bus=0x57b46e28, n=0, assign=true) at hw/virtio/virtio-bus.c:283 #9 0x558ce648 in virtio_blk_data_plane_start (vdev=0x57b46ea0) at /home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200 #10 0x55c24af2 in virtio_bus_start_ioeventfd (bus=0x57b46e28) at hw/virtio/virtio-bus.c:223 #11 0x55c26e57 in virtio_pci_start_ioeventfd (proxy=0x57b3ed30) at hw/virtio/virtio-pci.c:282 #12 0x55c29285 in virtio_pci_common_write (opaque=0x57b3ed30, addr=20, val=15, size=1) at hw/virtio/virtio-pci.c:1233 #13 0x55881ebd in memory_region_write_accessor (mr=0x57b3f700, addr=20, value=0x7fffcdf23f38, size=1, shift=0, mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502 #14 0x558820cd in access_with_adjusted_size (addr=20, value=0x7fffcdf23f38, size=1, access_size_min=1, access_size_max=4, access_fn= 0x55881dd4 , mr=0x57b3f700, attrs=...) at /home/usuario/Documentos/qemu/memory.c:568 #15 0x55885100 in memory_region_dispatch_write (mr=0x57b3f700, addr=20, data=15, size=1, attrs=...) at /home/usuario/Documentos/qemu/memory.c:1499 #16 0x5581bca9 in flatview_write_continue (fv=0x7fffb8000fc0, addr=34644951060, attrs=..., buf=0x77ff4028 , len=1, addr1=20, l=1, mr=0x57b3f700) at /home/usuario/Documentos/qemu/exec.c:3234 #17 0x5581bdf3 in flatview_write (fv=0x7fffb8000fc0, addr=34644951060, attrs=..., buf=0x77ff4028 , len=1) at /home/usuario/Documentos/qemu/exec.c:3273 #18 0x5581c0f9 in address_space_write (as=0x567e5a00 , addr=34644951060, attrs=..., buf=0x77ff4028 , len=1) at /home/usuario/Documentos/qemu/exec.c:3363 #19 0x5581c14a in address_space_rw (as=0x567e5a00 , addr=34644951060, attrs=..., buf=0x77ff4028 , len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374 #20 0x558a146f in kvm_cpu_exec (cpu=0x56bcc410) at /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031 #21 0x55865a3e in qemu_kvm_cpu_thread_fn (arg=0x56bcc410) at /home/usuario/Documentos/qemu/cpus.c:1281 #22 0x55e1ba02 in qemu_thread_start (args=0x56bedaa0) at util/qemu-thread-posix.c:502 #23 0x7072b6db in start_thread (arg=0x7fffcdf27700) at pthread_create.c:463 #24 0x7045488f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga
I can confirm this, KDE Neon using the command line similar to yours crashes QEMU to me too. I will test with Mageia 7 later to see if it behaves differently. But this is a completely different crash. This crash is happening earlier, what I reported first is a crash when the login screen should load, this is happening earlier on boot. The command line I used this time: qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 4G -drive if=virtio,file=neonbroken.qcow2 -vga qxl -bios /usr/share/ovmf/OVMF.fd The backtrace: (gdb) bt #0 0x70371e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x70373801 in __GI_abort () at abort.c:79 #2 0x5589eac9 in kvm_mem_ioeventfd_add (listener=0x56a1fdc8, section=0x7fffc7ffba90, match_data=false, data=0, e=0x578c7fc8) at /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866 #3 0x5588300a in address_space_add_del_ioeventfds (as=0x567e5a00 , fds_new=0x7fffbc000d30, fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at /home/usuario/Documentos/qemu/memory.c:793 #4 0x558832f4 in address_space_update_ioeventfds (as=0x567e5a00 ) at /home/usuario/Documentos/qemu/memory.c:843 #5 0x5588415b in memory_region_transaction_commit () at /home/usuario/Documentos/qemu/memory.c:1094 #6 0x558871c8 in memory_region_add_eventfd (mr=0x578b6420, addr=0, size=0, match_data=false, data=0, e=0x578c7fc8) at /home/usuario/Documentos/qemu/memory.c:2303 #7 0x55c26cd0 in virtio_pci_ioeventfd_assign (d=0x578b5750, notifier=0x578c7fc8, n=0, assign=true) at hw/virtio/virtio-pci.c:243 #8 0x55c24dd5 in virtio_bus_set_host_notifier (bus=0x578bd848, n=0, assign=true) at hw/virtio/virtio-bus.c:283 #9 0x558ce648 in virtio_blk_data_plane_start (vdev=0x578bd8c0) at /home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200 #10 0x55c24af2 in virtio_bus_start_ioeventfd (bus=0x578bd848) at hw/virtio/virtio-bus.c:223 #11 0x55c26e57 in virtio_pci_start_ioeventfd (proxy=0x578b5750) at hw/virtio/virtio-pci.c:282 #12 0x55c29285 in virtio_pci_common_write (opaque=0x578b5750, addr=20, val=15, size=1) at hw/virtio/virtio-pci.c:1233 #13 0x55881ebd in memory_region_write_accessor (mr=0x578b6120, addr=20, value=0x7fffc7ffbf38, size=1, shift=0, mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502 #14 0x558820cd in access_with_adjusted_size (addr=20, value=0x7fffc7ffbf38, size=1, access_size_min=1, access_size_max=4, access_fn=0x55881dd4 , mr=0x578b6120, attrs=...) at /home/usuario/Documentos/qemu/memory.c:568 #15 0x55885100 in memory_region_dispatch_write (mr=0x578b6120, addr=20, data=15, size=1, attrs=...) at /home/usuario/Documentos/qemu/memory.c:1499 #16 0x5581bca9 in flatview_write_continue (fv=0x7fffcc50f4f0, addr=34359738388, attrs=..., buf=0x77fee028 "\017", len=1, addr1=20, l=1, mr=0x578b6120) at /home/usuario/Documentos/qemu/exec.c:3234 #17 0x5581bdf3 in flatview_write (fv=0x7fffcc50f4f0, addr=34359738388, attrs=..., buf=0x77fee028 "\017", len=1) at /home/usuario/Documentos/qemu/exec.c:3273 #18 0x5581c0f9 in address_space_write (as=0x567e5a00 , addr=34359738388, attrs=..., buf=0x77fee028 "\017", len=1) at /home/usuario/Documentos/qemu/exec.c:3363 #19 0x5581c14a in address_space_rw (as=0x567e5a00 , addr=34359738388, attrs=..., buf=0x77fee028 "\017", len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374 #20 0x558a146f in kvm_cpu_exec (cpu=0x56afe140) at /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031 #21 0x55865a3e in qemu_kvm_cpu_thread_fn (arg=0x56afe140) at /home/usuario/Documentos/qemu/cpus.c:1281 #22 0x55e1ba02 in qemu_thread_start (args=0x56b20440) at util/qemu-thread-posix.c:502 #23 0x7072b6db in start_thread (arg=0x7fffc7fff700) at pthread_create.c:463 #24 0x7045488f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Às 11:36 de 01/02/2019, Dr. David Alan Gilbert escreveu: > > Hmm, I'm also getting a crash, but I think it's very different from > yours: > > ./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 8G -cdrom > /home/vmimages/neon-useredition-current.iso -drive > if=virtio,file=/home/vmimages/kde-neon.qcow2 -vga qxl > > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device > Aborted (core dumped) > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga
libspice-server1 on host: 0.14.0-1ubuntu2.2 spice-vdagent (the only package) on guest: 0.17.0-1ubuntu2 Guest kernel version: 4.15.0-44-generic > > OK, great; can can you confirm the version of the spice packages > on both the guest and host, and the kernel on the guest. > > Dave > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga
Here is the backtrace with the debug symbols added: (gdb) bt #0 0x70373e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x70375801 in __GI_abort () at abort.c:79 #2 0x71171cc9 in spice_logv (log_domain=0x711dc9f5 "Spice", args=0x7fff36028cb0, format=0x711e3c5b "slot_id %d too big, addr=%lx", function=0x711e3d90 <__FUNCTION__.15594> "memslot_get_virt", strloc=0x711e3c78 "memslot.c:111", log_level=G_LOG_LEVEL_CRITICAL) at log.c:183 #3 0x71171cc9 in spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x711e3c78 "memslot.c:111", function=function@entry=0x711e3d90 <__FUNCTION__.15594> "memslot_get_virt", format=format@entry=0x711e3c5b "slot_id %d too big, addr=%lx") at log.c:196 #4 0x711373b8 in memslot_get_virt (info=info@entry=0x579b8630, addr=addr@entry=18374686483949813760, add_size=add_size@entry=10, group_id=group_id@entry=1, error=error@entry=0x7fff36028e08) at memslot.c:111 #5 0x711407d0 in red_get_image (slots=slots@entry=0x579b8630, group_id=group_id@entry=1, addr=, flags=flags@entry=0, is_mask=is_mask@entry=false) at red-parse-qxl.c:512 #6 0x71140a76 in red_get_copy_ptr (slots=slots@entry=0x579b8630, group_id=group_id@entry=1, red=red@entry=0x7fff1409f5f0, qxl=0x7fff1fe0107b, flags=flags@entry=0) at red-parse-qxl.c:680 #7 0x711419a1 in red_get_native_drawable (flags=, addr=, red=, group_id=, slots=) at red-parse-qxl.c:1072 #8 0x711419a1 in red_get_drawable (slots=slots@entry=0x579b8630, group_id=1, red=red@entry=0x7fff1409f550, addr=, flags=0) at red-parse-qxl.c:1206 #9 0x711543cd in red_process_display (worker=0x579b85a0, ring_is_empty=0x7fff36028f9c) at red-worker.c:224 #10 0x71152d21 in flush_commands (worker=worker@entry=0x579b85a0, red_channel=0x579b4a10, process=process@entry=0x71154220 ) at red-worker.c:315 #11 0x71152e58 in flush_display_commands (worker=worker@entry=0x579b85a0) at red-worker.c:352 #12 0x711534bf in flush_all_qxl_commands (worker=0x579b85a0) at red-worker.c:367 #13 0x711534bf in destroy_primary_surface (worker=0x579b85a0, surface_id=0) at red-worker.c:558 #14 0x711214f1 in dispatcher_handle_single_read (dispatcher=0x56a0c1c0) at dispatcher.c:284 #15 0x711214f1 in dispatcher_handle_recv_read (dispatcher=0x56a0c1c0) at dispatcher.c:304 #16 0x71127d7b in watch_func (source=, condition=, data=0x579b8780) at event-loop.c:128 #17 0x747931f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #18 0x747935c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #19 0x747938d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #20 0x71153b3a in red_worker_main (arg=0x579b85a0) at red-worker.c:1372 #21 0x7072d6db in start_thread (arg=0x7fff3602c700) at pthread_create.c:463 #22 0x7045688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Às 10:13 de 28/01/2019, Dr. David Alan Gilbert escreveu: > > Thanks for the report, > > Could you install the debug packages of libspice-server on your system > so that the backtrace you get has symbols? > > Dave >
[Qemu-devel] Crash when booting KDE Neon using qxl-vga
With QEMU version 3.1.50 (v3.1.0-1218-gad7a21e812-dirty) (commit ad7a21e81231ae64540310384fb0f87ac8758b02) on Xubuntu 18.04 host, a KDE Neon guest is crashing on boot. The QEMU command line is: gdb -q -ex "set pagination off" -ex "set print thread-events off" -ex "handle SIGUSR1 nostop nopass noprint" -ex "run" --args qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048 -hda neonbroken.qcow2 -cdrom ~/Downloads/neon-useredition-20190124-0530-amd64.iso -device qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd The crash is happening pretty frequently but not 100% of the times. Using virtio-vga instead of qxl-vga it's possible to use the guest normally. Before the crash there are some graphical artifacts on guest screen, they can be seen at https://i.imgur.com/rfTmmJ0.png On terminal QEMU prints the following messages: $ qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048 -hda neonbroken.qcow2 -cdrom ~/Downloads/neon-useredition-20190124-0530-amd64.iso -device qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd (qemu-system-x86_64:11683): Gtk-WARNING **: 18:18:34.797: Theme parsing error: gtk.css:47:15: negative values are not allowed. id 0, group 0, virt start 0, virt end , generation 0, delta 0 id 1, group 1, virt start 7ff31fe0, virt end 7ff323dfe000, generation 0, delta 7ff31fe0 id 2, group 1, virt start 7ff31bc0, virt end 7ff31fc0, generation 0, delta 7ff31bc0 (qemu:11683): Spice-CRITICAL **: 18:39:40.747: memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff00ff00 Abortado (imagem do núcleo gravada) Here is the backtrace: (gdb) bt #0 0x70373e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x70375801 in __GI_abort () at abort.c:79 #2 0x71171cc9 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #3 0x711373b8 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #4 0x711407d0 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #5 0x71140a76 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #6 0x711419a1 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #7 0x711543cd in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #8 0x71152d21 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #9 0x711534bf in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #10 0x711214f1 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #11 0x71127d7b in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #12 0x747931f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x747935c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x747938d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x71153b3a in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 #16 0x7072d6db in start_thread (arg=0x7fff3602c700) at pthread_create.c:463
Re: [Qemu-devel] Guests are crashing on startup, seem related to usb-audio
I am testing this QEMU build in two VM guests, one Mageia 7 and other
openSUSE Leap. They reach the graphical session, play a sound using
aplay and reboot automatically. The screen and audio from the host were
captured to check if the sound would work even with the warning.
Once, the Mageia 7 guest had in the terminal:
qemu-system-x86_64: warning: usb-audio: 0/192
And it continued operating normally, with no crash or freeze and sound
played normally. One video showing its behavior can be seen on this link:
https://cdn.discordapp.com/attachments/457747189616214019/521744887192879120/qemu-teste-audio002.webm
The sound quality in the video is worse than normal because the Mageia
guest sample rate is set to 44100 Hz while the usb-audio sample rate is
48000 Hz and because FFmpeg "magnifies" certain audio issues.
The openSUSE guest has once shown the following:
qxl_send_events: spice-server bug: guest stopped, ignoring
[Thread 0x7fffcf7fe700 (LWP 12771) exited]
[New Thread 0x7fffcf7fe700 (LWP 13036)]
[Thread 0x7fffcf7fe700 (LWP 13036) exited]
[New Thread 0x7fffcf7fe700 (LWP 13067)]
[Thread 0x7fffcf7fe700 (LWP 13067) exited]
[New Thread 0x7fffcf7fe700 (LWP 13098)]
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
qemu-system-x86_64: warning: usb-audio: 0/192
While it did not crash, its screen froze. By the QXL message, it seems
the bug https://bugs.launchpad.net/qemu/+bug/1787070 is still present
and causing failures on guests too, with openSUSE still being the
biggest victim.
Regarding this specific usb-audio crash problem, QEMU from
sirius/usb-audio-crash seems to be fixed.
Às 10:56 de 10/12/2018, kra...@redhat.com escreveu:
> On Mon, Dec 10, 2018 at 12:11:09PM +0000, Leonardo Soares Müller wrote:
>> Hi, I did not save that Mageia 7 data as I was unaware I could do this.
>> The data below is from another crash with openSUSE Leap, this time I
>> saved this backtrace with generate-core-file.
>
>> On #4 it shows:
>> $2 = {pid = 225, id = 2027203168, ep = 0x57e46520, stream = 0, iov =
>> {iov = 0x7fffc418d190, niov = 0, nalloc = 1, size = 0}, parameter = 0,
>
>> short_not_ok = false, int_req = false, status = 0, actual_length = 0,
>> state = USB_PACKET_SETUP, combined = 0x0, queue = {tqe_next = 0x0,
>> tqe_prev = 0x0}, combined_entry = {tqe_next = 0x0, tqe_prev = 0x0}}
>
> Hmm, zero-length usb package. Should be 192 bytes ...
>
> Does anything change with
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/usb-audio-crash ?
>
> thanks,
> Gerd
>
Re: [Qemu-devel] Guests are crashing on startup, seem related to usb-audio
Hi, I did not save that Mageia 7 data as I was unaware I could do this. The data below is from another crash with openSUSE Leap, this time I saved this backtrace with generate-core-file. QEMU command line: env QEMU_AUDIO_ADC_VOICES=0 QEMU_AUDIO_DRV=pa \ QEMU_AUDIO_DAC_FIXED_FREQ=96000 \ QEMU_AUDIO_ADC_FIXED_FREQ=96000 \ QEMU_AUDIO_ADC_VOICES=0 \ gdb -ex "handle SIGUSR1 nostop nopass noprint" -ex "run" --args qemu-system-x86_64 \ -name "openSUSE Leap" -k pt-br -nodefaults -enable-kvm -cpu host -smp cores=2,threads=1 -m 2G \ -device qemu-xhci,id=xhcihub -device usb-audio,id=usbaudio,buffer=6144 \ -device virtio-tablet-pci,id=pcitablet -bios /usr/share/ovmf/OVMF.fd \ -device qxl-vga,xres=800,yres=600 -display gtk,gl=on \ -hda /home/usuario/.local/share/libvirt/images/opensuse_leap.qcow2 \ -monitor vc -serial vc \ -machine kernel_irqchip=on -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -M pc,usb=true \ -netdev user,id=net0 -device e1000,netdev=net0,addr=8 gdb backtrace: #0 0x701cce97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x701ce801 in __GI_abort () at abort.c:79 #2 0x701be39a in __assert_fail_base (fmt=0x7fffd403e202 "%s%s%s:%u: %s%sAssertiva “%s” falhou.\n%n", assertion=assertion@entry=0x55fb8738 "p->actual_length + bytes <= iov->size", file=file@entry=0x55fb8456 "hw/usb/core.c", line=line@entry=592, function=function@entry=0x55fb8980 <__PRETTY_FUNCTION__.26351> "usb_packet_copy") at assert.c:92 #3 0x701be412 in __GI___assert_fail (assertion=0x55fb8738 "p->actual_length + bytes <= iov->size", file=0x55fb8456 "hw/usb/core.c", line=592, function=0x55fb8980 <__PRETTY_FUNCTION__.26351> "usb_packet_copy") at assert.c:101 #4 0x55bd5ed7 in usb_packet_copy (p=0x7fffc4174128, ptr=0x7fffb801e390, bytes=192) at hw/usb/core.c:592 #5 0x55c024d8 in streambuf_put (buf=0x57e468a0, p=0x7fffc4174128) at hw/usb/dev-audio.c:325 #6 0x55c02d78 in usb_audio_handle_dataout (s=0x57e451b0, p=0x7fffc4174128) at hw/usb/dev-audio.c:596 #7 0x55c02e16 in usb_audio_handle_data (dev=0x57e451b0, p=0x7fffc4174128) at hw/usb/dev-audio.c:608 #8 0x55bd7c39 in usb_device_handle_data (dev=0x57e451b0, p=0x7fffc4174128) at hw/usb/bus.c:184 #9 0x55bd54a9 in usb_process_one (p=0x7fffc4174128) at hw/usb/core.c:388 #10 0x55bd5668 in usb_handle_packet (dev=0x57e451b0, p=0x7fffc4174128) at hw/usb/core.c:420 #11 0x55bf6d8e in xhci_submit (xhci=0x7fffcd538010, xfer=0x7fffc4174120, epctx=0x7fffc4172f40) at hw/usb/hcd-xhci.c:1819 #12 0x55bf6df6 in xhci_fire_transfer (xhci=0x7fffcd538010, xfer=0x7fffc4174120, epctx=0x7fffc4172f40) at hw/usb/hcd-xhci.c:1828 #13 0x55bf73eb in xhci_kick_epctx (epctx=0x7fffc4172f40, streamid=0) at hw/usb/hcd-xhci.c:1969 #14 0x55bf6eef in xhci_kick_ep (xhci=0x7fffcd538010, slotid=1, epid=2, streamid=0) at hw/usb/hcd-xhci.c:1853 #15 0x55bfa0ac in xhci_doorbell_write (ptr=0x7fffcd538010, reg=1, val=2, size=4) at hw/usb/hcd-xhci.c:3125 #16 0x5587f44e in memory_region_write_accessor (mr=0x7fffcd538d60, addr=4, value=0x7fffceeb80b8, size=4, shift=0, mask=4294967295, attrs=...) at /home/usuario/Documentos/qemu/memory.c:504 #17 0x5587f65e in access_with_adjusted_size (addr=4, value=0x7fffceeb80b8, size=4, access_size_min=1, access_size_max=4, access_fn= 0x5587f365 , mr=0x7fffcd538d60, attrs=...) at /home/usuario/Documentos/qemu/memory.c:570 #18 0x55882359 in memory_region_dispatch_write (mr=0x7fffcd538d60, addr=4, data=2, size=4, attrs=...) at /home/usuario/Documentos/qemu/memory.c:1452 #19 0x5581d359 in flatview_write_continue (fv=0x7fffc4188bc0, addr=34359762948, attrs=..., buf=0x77ff3028 "\002", len=4, addr1=4, l=4, mr=0x7fffcd538d60) at /home/usuario/Documentos/qemu/exec.c:3233 #20 0x5581d4a3 in flatview_write (fv=0x7fffc4188bc0, addr=34359762948, attrs=..., buf=0x77ff3028 "\002", len=4) at /home/usuario/Documentos/qemu/exec.c:3272 #21 0x5581d7a9 in address_space_write (as=0x567d6460 , addr=34359762948, attrs=..., buf=0x77ff3028 "\002", len=4) at /home/usuario/Documentos/qemu/exec.c:3362 #22 0x5581d7fa in address_space_rw (as=0x567d6460 , addr=34359762948, attrs=..., buf=0x77ff3028 "\002", len=4, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3373 #23 0x5589ea33 in kvm_cpu_exec (cpu=0x56b9ddf0) at /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031 #24 0x5586453b in qemu_kvm_cpu_thread_fn (arg=0x56b9ddf0) at /home/usuario/Documentos/qemu/cpus.c:1281 #25 0x55e11d07 in qemu_thread_start (args=0x56bbe520) at util/qemu-thread-posix.c:498 #26 0x705866db in start_thread (arg=0x7fffceebb700) at pthread_create.c:463 #27 0x702af88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 On #3 it outputs: No symbol "p" in current context. On #4 it shows: $2
[Qemu-devel] Guests are crashing on startup, seem related to usb-audio
Linux guests are crashing on startup, this crash happens rarely and, after boot, it is even rarer but happened at least once with an Ubuntu 18.04 guest. The host OS is Xubuntu 18.04, happens with multiple kernel versions, current is 4.20.0-rc5-drm-tip-d63c50f2b014037b43c1c0f108c61e0a31ede3c1+ QEMU version from git: 4750e1a888ac3d320607f33b676f299005be98e6 $ qemu-system-x86_64 --version QEMU emulator version 3.0.93 (v3.1.0-rc3-dirty) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers The crashes were observed with the following guests, being very rare: Ubuntu 18.04; Ubuntu 18.10; CentOS 7.5; openSUSE Leap 15.0; Mageia 6; The following guest OS is crashing with this much more commonly than others and is the guest used to get the backtrace: Mageia 7 Beta 1; Pastes with information: Backtrace: https://paste.ubuntu.com/p/XzK4vcHTwF/ QEMU command line: https://paste.ubuntu.com/p/4NqM4k9JPS/ This particular guest uses Intel GVT-g, but the crash was observed using virtio-vga and qxl-vga too. The command line to start the guest was (If the pastes expire): env QEMU_AUDIO_ADC_VOICES=0 QEMU_AUDIO_DRV=pa \ QEMU_AUDIO_DAC_FIXED_FREQ=96000 \ QEMU_AUDIO_ADC_FIXED_FREQ=96000 \ QEMU_AUDIO_ADC_VOICES=0 \ gdb -ex "handle SIGUSR1 nostop nopass noprint" -ex "run" --args qemu-system-x86_64 \ -name "Mageia 7" -k pt-br -nodefaults -enable-kvm -cpu host -smp cores=2,threads=1 -m 2G \ -device vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:02.0/7c6999bc-d8a6-11e8-951d-a75a7e70a07f,rombar=0,display=on,addr=0x3,id=iHD520 \ -device qemu-xhci,id=xhcihub -device usb-tablet,id=usbtablet -device usb-audio,id=usbaudio,buffer=6144 -bios /usr/share/ovmf/OVMF.fd \ -display gtk,gl=on -hda /home/usuario/.local/share/libvirt/images/mageia7.qcow2 -monitor vc -serial mon:stdio \ -machine kernel_irqchip=on -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -M pc,usb=true \ -netdev user,id=net0 -device e1000,netdev=net0,addr=8 The backtrace obtained: (gdb) bt #0 0x701cce97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x701ce801 in __GI_abort () at abort.c:79 #2 0x701be39a in __assert_fail_base (fmt=0x77e1f202 "%s%s%s:%u: %s%sAssertiva “%s” falhou.\n%n", assertion=assertion@entry=0x55fb8738 "p->actual_length + bytes <= iov->size", file=file@entry=0x55fb8456 "hw/usb/core.c", line=line@entry=592, function=function@entry=0x55fb8980 <__PRETTY_FUNCTION__.26351> "usb_packet_copy") at assert.c:92 #3 0x701be412 in __GI___assert_fail (assertion=0x55fb8738 "p->actual_length + bytes <= iov->size", file=0x55fb8456 "hw/usb/core.c", line=592, function=0x55fb8980 <__PRETTY_FUNCTION__.26351> "usb_packet_copy") at assert.c:101 #4 0x55bd5ed7 in usb_packet_copy (p=0x7fffc4722ea8, ptr=0x7fffbc053ee0, bytes=192) at hw/usb/core.c:592 #5 0x55c024d8 in streambuf_put (buf=0x57ed1040, p=0x7fffc4722ea8) at hw/usb/dev-audio.c:325 #6 0x55c02d78 in usb_audio_handle_dataout (s=0x57ecf950, p=0x7fffc4722ea8) at hw/usb/dev-audio.c:596 #7 0x55c02e16 in usb_audio_handle_data (dev=0x57ecf950, p=0x7fffc4722ea8) at hw/usb/dev-audio.c:608 #8 0x55bd7c39 in usb_device_handle_data (dev=0x57ecf950, p=0x7fffc4722ea8) at hw/usb/bus.c:184 #9 0x55bd54a9 in usb_process_one (p=0x7fffc4722ea8) at hw/usb/core.c:388 #10 0x55bd5668 in usb_handle_packet (dev=0x57ecf950, p=0x7fffc4722ea8) at hw/usb/core.c:420 #11 0x55bf6d8e in xhci_submit (xhci=0x7fffce40b010, xfer=0x7fffc4722ea0, epctx=0x7fffc41c35b0) at hw/usb/hcd-xhci.c:1819 #12 0x55bf6df6 in xhci_fire_transfer (xhci=0x7fffce40b010, xfer=0x7fffc4722ea0, epctx=0x7fffc41c35b0) at hw/usb/hcd-xhci.c:1828 #13 0x55bf73eb in xhci_kick_epctx (epctx=0x7fffc41c35b0, streamid=0) at hw/usb/hcd-xhci.c:1969 #14 0x55bf6eef in xhci_kick_ep (xhci=0x7fffce40b010, slotid=2, epid=2, streamid=0) at hw/usb/hcd-xhci.c:1853 #15 0x55bfa0ac in xhci_doorbell_write (ptr=0x7fffce40b010, reg=2, val=2, size=4) at hw/usb/hcd-xhci.c:3125 #16 0x5587f44e in memory_region_write_accessor (mr=0x7fffce40bd60, addr=8, value=0x7fffcfeba0b8, size=4, shift=0, mask=4294967295, attrs=...) at /home/usuario/Documentos/qemu/memory.c:504 #17 0x5587f65e in access_with_adjusted_size (addr=8, value=0x7fffcfeba0b8, size=4, access_size_min=1, access_size_max=4, access_fn= 0x5587f365 , mr=0x7fffce40bd60, attrs=...) at /home/usuario/Documentos/qemu/memory.c:570 #18 0x55882359 in memory_region_dispatch_write (mr=0x7fffce40bd60, addr=8, data=2, size=4, attrs=...) at /home/usuario/Documentos/qemu/memory.c:1452 #19 0x5581d359 in flatview_write_continue (fv=0x7fffbc896810, addr=34644959240, attrs=..., buf=0x77ff3028 "\002", len=4, addr1=8, l=4, mr=0x7fffce40bd60) at /home/usuario/Documentos/qemu/exec.c:3233 #20 0x5581d4a3 in flatview_write (fv=0x7fffbc896810, addr=34644959240, attrs=...,
