Description of problem: Restoring a libvirt domain (created by Boxes) from saved state (migration codepath is used here last I checked) always leads to this qemu crash. I first thought that this is the same issue one gets in every other release: new libvirt+qemu is unable to restore domain saved by older libvirt+qemu. However, I'm able to consistently reproduce this issue even after I saved the domain using the new libvirt+qemu in Fedora 19. Version-Release number of selected component: qemu-system-x86-1.4.1-1.fc19 Additional info: reporter: libreport-2.1.4 backtrace_rating: 4 cmdline: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedora18-2 -S -M pc-1.2 -cpu Westmere,+rdtscp,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 1152 -smp 4,sockets=1,cores=2,threads=2 -uuid 444f6b31-e7f0-c6f4-5d72-3dbbe8ac837a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/zeenix/.config/libvirt/qemu/lib/fedora18-2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/zeenix/.local/share/gnome-boxes/images/fedora18-2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev user,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:6a:44:79,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device AC97,id=sound0,bus=pci.0,addr=0x4 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -incoming fd:18 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 crash_function: usbredirparser_peer_has_cap executable: /usr/bin/qemu-system-x86_64 kernel: 3.9.1-301.fc19.x86_64 runlevel: N 5 uid: 500 xsession_errors: Truncated backtrace: Thread no. 1 (9 frames) #0 usbredirparser_peer_has_cap at usbredirparser.c:212 #1 usbredir_check_bulk_receiving at hw/usb/redirect.c:1398 #2 usbredir_post_load at hw/usb/redirect.c:2030 #3 vmstate_load_state at /usr/src/debug/qemu-1.4.1/savevm.c:1484 #4 qemu_loadvm_state at /usr/src/debug/qemu-1.4.1/savevm.c:2010 #5 process_incoming_migration_co at migration.c:97 #6 coroutine_trampoline at coroutine-ucontext.c:138 #7 ?? at /lib64/libc.so.6 #8 ??
Created attachment 747705 [details] File: backtrace
Created attachment 747706 [details] File: cgroup
Created attachment 747707 [details] File: core_backtrace
Created attachment 747708 [details] File: dso_list
Created attachment 747709 [details] File: environ
Created attachment 747710 [details] File: limits
Created attachment 747711 [details] File: maps
Created attachment 747712 [details] File: open_fds
Created attachment 747713 [details] File: proc_pid_status
Created attachment 747714 [details] File: var_log_messages
Hans, usbredir crash, thoughts?
(In reply to comment #11) > Hans, usbredir crash, thoughts? Yes, this is fixed by this upstream commit: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3713e1485e6eace7d48b9c790602cfd92c616e5f Regards, Hans
(In reply to comment #12) > (In reply to comment #11) > > Hans, usbredir crash, thoughts? > > Yes, this is fixed by this upstream commit: > http://git.qemu.org/?p=qemu.git;a=commitdiff; > h=3713e1485e6eace7d48b9c790602cfd92c616e5f Oh cool, its fixed already. :) This makes it very hard to use/work on Boxes so bumping severity. Hope we can soon have a new qemu build with this patch?
qemu-1.4.1-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qemu-1.4.1-2.fc19
qemu-1.4.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qemu-1.4.1-3.fc19
Package qemu-1.4.1-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qemu-1.4.1-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8354/qemu-1.4.1-3.fc19 then log in and leave karma (feedback).
This is a showstopper for Boxes in F19, apparently. We've fixed virt-manager now so Boxes being broken isn't a blocker, but it would be good to fix it, I think. Proposing as a freeze exception.
+1 to Freeze Exception
+1 to Freeze Exception given that virt-install has always worked and virt-manager is now also patched.
qemu-1.4.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
qemu-1.4.2-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qemu-1.4.2-1.fc19
qemu-1.4.2-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qemu-1.4.2-2.fc19
qemu-1.4.2-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.