- Package:
- qemu-system-x86
- Source:
- qemu
- Description:
- QEMU full system emulation binaries (x86)
- Submitter:
- Kyle Gordon
- Date:
- 2025-08-11 08:59:04 UTC
- Severity:
- normal
Dear Maintainer, Over the course of the past few weeks, a guest KVM instance that relies on USB pass through has been found in the powered off state. Restarting it shows that it has been hard powered off. This is now reproducible with the connected RFXCom hardware. Guest OS = Debian Jessie Host OS = Debian Jessie Start guest machine, and configure USB pass through. In this case, it's for an RFXCom USB radio transceiver. Device is correctly detected in the guest, and shows up as expected in lsusb. Start software that accesses the device. In this case, Domoticz home automation software. Within a few minutes, the machine will be hard powered off. The following logs are present on the host. 2017-01-01 23:40:27.179+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm -name homeauto -S -machine pc-i440fx-2.1,accel=kvm,usb=off -m 6144 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid a79858f4-274e-425f-aece-98c14dc8fbc6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/homeauto.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/media/store/KVM_VMs/homeauto-new.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/media/store/KVM_VMs/homeauto-new-1.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/media/store/KVM_VMs/homeauto-new-3.qcow2,if=none,id=drive-virtio-disk2,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xa,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:38:01:2d,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=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -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 -device usb-host,hostbus=6,hostaddr=4,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on char device redirected to /dev/pts/1 (label charserial0) main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 2.497000 ms, bitrate 41698055 bps (39.766364 Mbps) red_dispatcher_set_cursor_peer: inputs_connect: inputs channel client create === Normal behaviour until Domoticz is started... === qemu-system-x86_64: /build/qemu-XXUWBP/qemu-2.1+dfsg/hw/usb/core.c:600: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. 2017-01-01 23:42:30.995+0000: shutting down I have tried 2.7+dfsg-3~bpo8+2 from jessie-backports, but the behaviour is the same. Unsure where to try next. Regards Kyle
Hi, This also causes guest Debian Stretch machines to terminate unexpectedly, and can also be triggered by an alternative home automation package called home-assistant. I think this is certainly pointing at the KVM/QEMU host being faulty in some way. Kyle
02.01.2017 02:54, Kyle Gordon wrote: Please verify whenever the same issue exists with a more recent qemu version, for example the one which is available in jessie-backports. Qemu is a fast-moving target, and in particular, usb passthrough has been revisited 2 times since 2.1 version. Lowering the severity to normal, since this problem does not _break_ anything per se, especially it does not break host system, it merely cases guest system to be turned off after a well-defined sequence of events which, as a work-around, can be avoided. Thanks, /mjt
02.01.2017 02:54, Kyle Gordon wrote: Please verify whenever the same issue exists with a more recent qemu version, for example the one which is available in jessie-backports. Qemu is a fast-moving target, and in particular, usb passthrough has been revisited 2 times since 2.1 version. Lowering the severity to normal, since this problem does not _break_ anything per se, especially it does not break host system, it merely cases guest system to be turned off after a well-defined sequence of events which, as a work-around, can be avoided. Thanks, /mjt
Hi Michael, Thanks for the response. I have tried upgrading qemu* to 2.7+dfsg-3~bpo8+2 from jessie-backports, and the behaviour is unfortunately the same. I haven't tried upgrading the system to Stretch yet, as that might be a bit of a one way road! Regards Kyle
Hi Michael, Thanks for the response. I have tried upgrading qemu* to 2.7+dfsg-3~bpo8+2 from jessie-backports, and the behaviour is unfortunately the same. I haven't tried upgrading the system to Stretch yet, as that might be a bit of a one way road! Regards Kyle
02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
Hey, I've managed to reproduce it on 2.7 from jessie-backports again, and the assert is... qemu-system-x86_64: /build/qemu-1VqMQS/qemu-2.7+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. Also, this has been known to happen when adding the USB device, leaving the VM in a 'Shutoff (Crashed)' state. I'm not sure if it's related. *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007f45d2b3a200 *** and ... *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007fa2cd10b560 *** I'll try the 2.8 version shortly! Cheers Kyle On Mon, Jan 2, 2017 at 11:06 AM Michael Tokarev <mjt@tls.msk.ru> wrote: 02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
Hey, I've managed to reproduce it on 2.7 from jessie-backports again, and the assert is... qemu-system-x86_64: /build/qemu-1VqMQS/qemu-2.7+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. Also, this has been known to happen when adding the USB device, leaving the VM in a 'Shutoff (Crashed)' state. I'm not sure if it's related. *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007f45d2b3a200 *** and ... *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007fa2cd10b560 *** I'll try the 2.8 version shortly! Cheers Kyle On Mon, Jan 2, 2017 at 11:06 AM Michael Tokarev <mjt@tls.msk.ru> wrote: 02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
Hi again! Managed to get 2.8 installed, and all the dependencies. I also grabbed the 2.8 version of everything else qemu* related 'just in case' Unfortunately... qemu-system-x86_64: /build/qemu-2.8/qemu-2.8+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. I did try 2.7 with another USB device, this time just a '1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter' on an ESP8266, and it worked just fine. I'm also wondering if it's hardware related, and will be swapping cables, etc over the coming days. However, an unreliable USB deivce shouldn't kill a VM, so maybe some protection is still required in the USB redirection handling code? Cheers Kyle On Tue, Jan 3, 2017 at 12:55 AM Kyle Gordon <kyle@lodge.glasgownet.com> wrote: Hey, I've managed to reproduce it on 2.7 from jessie-backports again, and the assert is... qemu-system-x86_64: /build/qemu-1VqMQS/qemu-2.7+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. Also, this has been known to happen when adding the USB device, leaving the VM in a 'Shutoff (Crashed)' state. I'm not sure if it's related. *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007f45d2b3a200 *** and ... *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007fa2cd10b560 *** I'll try the 2.8 version shortly! Cheers Kyle On Mon, Jan 2, 2017 at 11:06 AM Michael Tokarev <mjt@tls.msk.ru> wrote: 02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
Hi again! Managed to get 2.8 installed, and all the dependencies. I also grabbed the 2.8 version of everything else qemu* related 'just in case' Unfortunately... qemu-system-x86_64: /build/qemu-2.8/qemu-2.8+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. I did try 2.7 with another USB device, this time just a '1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter' on an ESP8266, and it worked just fine. I'm also wondering if it's hardware related, and will be swapping cables, etc over the coming days. However, an unreliable USB deivce shouldn't kill a VM, so maybe some protection is still required in the USB redirection handling code? Cheers Kyle On Tue, Jan 3, 2017 at 12:55 AM Kyle Gordon <kyle@lodge.glasgownet.com> wrote: Hey, I've managed to reproduce it on 2.7 from jessie-backports again, and the assert is... qemu-system-x86_64: /build/qemu-1VqMQS/qemu-2.7+dfsg/hw/usb/core.c:584: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. Also, this has been known to happen when adding the USB device, leaving the VM in a 'Shutoff (Crashed)' state. I'm not sure if it's related. *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007f45d2b3a200 *** and ... *** Error in `qemu-system-x86_64': double free or corruption (!prev): 0x00007fa2cd10b560 *** I'll try the 2.8 version shortly! Cheers Kyle On Mon, Jan 2, 2017 at 11:06 AM Michael Tokarev <mjt@tls.msk.ru> wrote: 02.01.2017 13:57, Kyle Gordon wrote: Hmm... I see. I re-read you first message, and it turns out I missed the info about the bpo version. Please excuse me for that, that's ENOCOFFEE :) This smells like something specific to this usb device. Did you try other devices? The thing is that usb passthrough generally works. Can you also please show where it asserts out in case of 2.7 version from bpo? Also there's 2.8 version built for bpo (but not uploaded yet, since 2.8 hasn't been entered -testing), available at http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb which can be of interest in this context too, but this might be too much for you to try (this version is built with gtk and virgl support, so there will be other deps). Thanks, /mjt
Version: 1:7.2+dfsg-1 Hi! It's been quite some time since this bug report had seen an activity. A lot of various USB devices has been used with qemu since that time, and qemu received a lot of improvements too. There hasn't been reports of USB device pass-through failures in quite a long time. Let's close this bug report with qemu version from bookworm. Please feel free to reopen it if you think the issue is still present (but please also try trixie version of qemu). Thanks, /mjt