diff options
Diffstat (limited to 'results/classifier/105/other/1511887')
| -rw-r--r-- | results/classifier/105/other/1511887 | 87 |
1 files changed, 87 insertions, 0 deletions
diff --git a/results/classifier/105/other/1511887 b/results/classifier/105/other/1511887 new file mode 100644 index 000000000..d998f7084 --- /dev/null +++ b/results/classifier/105/other/1511887 @@ -0,0 +1,87 @@ +other: 0.954 +instruction: 0.934 +device: 0.929 +graphic: 0.925 +assembly: 0.925 +semantic: 0.914 +network: 0.903 +boot: 0.898 +mistranslation: 0.868 +vnc: 0.845 +KVM: 0.837 +socket: 0.831 + +USB device 1.1 not correctly passedthru from Linux host to Windows guest + +I have USB Digital Oscilloscope which works great on pure Windows machine but not work on virtualized one. I tried passthru the device from my Debian Jessie (64bit) host machine to Windows 7 (32bit) guest machine but unfortunately it does not work very well. It looks that device is passed thru so Windows machine knows about new device and loads HID device driver for it but the device driver failed to start the device and details of an error provided by device manager is "This device cannot start" Code 10. + +Installed Qemu version: 2.1+dfsg-12+deb8u4 0 + +USB device spec: Dynon Instruments ELAB-080, USB 1.1 + +On linux host computer +--------------------------- +lsusb identify it as: +Bus 003 Device 009: ID 13a3:0001 + +lsusb -t identify it as: +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M + |__ Port 1: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 12M + +This is how I started my Windows guest machine +------------------------------------------------------ +kvm -cpu host \ + -m 2048MiB \ + -hda test.vdi \ + -ctrl-grab \ + -parallel /dev/parport0 \ + -usbdevice host:13a3:0001 + +...also instead of last line I tried this one: + -device usb-host,vendorid=0x13a3,productid=0x0001 + +none of them help to properly handle my device inside guest machine. + +Only one time the Windows guest machine properly start the device so software for that oscilloscope can identify the Oscilloscope and measure for a while but unfortunately after I guess 5 seconds of measurement the device was disconnected from Windows and never start working again even after couple of restarts of guest machine even after plug and unplug it's USB cable and power cable. + +I searched for a solution or some clues to get it work but none of my searching over the internet was successful. Because device works on pure Windows but not work on virtualized one, I think there is a problem with handling not standard USB devices (like sticks, keyboards, mouses etc.) + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)? + +Currently I can reproduce this bug with 2.8+dfsg-3~bpo8+1 version because I'm using stable Debian GNU/Linux. I'll try install latest qemu test it and report back here. + +In commnet #2 I promised to do test with latest qemu 2.9. I'm back here to report what I've done and what's my findings. + +1) I've downloaded newest Qemu 2.9.0 released at Apr 20 2017 from qemu.org website. +2) I've compiled it on fully updated Debian Jessie using following extra parameters: ../configure --enable-kvm --enable-libusb and then make +3) I tried to start my Windows guest machine using following command: + +x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -M q35,accel=kvm \ + -m 2048 \ + -cpu host \ + -hda test.vdi \ + -usb \ + -device usb-host,vendorid=0x13a3,productid=0x0001 + +After Windows guest started I plugged in my USB Oscilloscope and get the same result in Windows Device Manager: "This device cannot start" Code 10. The result is completely the same as before. + +4) In terminal I got following errors: + +libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/2-1/bConfigurationValue failed ret=-1 errno=2 +libusb: error [op_set_configuration] failed, error -1 errno 71 +qemu-system-x86_64: libusb_set_configuration: -99 [OTHER] + +NOTE: libusb-dev version used during compile was 1.0.19-1 + +RESULT: I can confirm and can reproduce for sure that the problem persist also in newest Qemu 2.9.0. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/118 + + |