Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#849884: qemu-kvm: USB host device pass through causes instant VM poweroff

73 views
Skip to first unread message

Kyle Gordon

unread,
Jan 2, 2017, 6:10:03 AM1/2/17
to
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

On Mon, Jan 2, 2017 at 7:57 AM Michael Tokarev <m...@tls.msk.ru> wrote:
Control: severity -1 normal
Control: reassign -1 qemu-system-x86

02.01.2017 02:54, Kyle Gordon wrote:
> Package: qemu-kvm
> Version: 1:2.1+dfsg-12+deb8u6
> Severity: critical
> Justification: breaks the whole system
>
> 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.

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

--
To unsubscribe, send mail to 849884-un...@bugs.debian.org.

Michael Tokarev

unread,
Jan 2, 2017, 6:10:03 AM1/2/17
to
02.01.2017 13:57, Kyle Gordon wrote:
> 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!

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

Kyle Gordon

unread,
Jan 2, 2017, 8:00:02 PM1/2/17
to
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

Kyle Gordon

unread,
Jan 3, 2017, 7:10:02 PM1/3/17
to
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
0 new messages