diff options
Diffstat (limited to 'results/classifier/118/all/685096')
| -rw-r--r-- | results/classifier/118/all/685096 | 364 |
1 files changed, 364 insertions, 0 deletions
diff --git a/results/classifier/118/all/685096 b/results/classifier/118/all/685096 new file mode 100644 index 000000000..81abe6bc5 --- /dev/null +++ b/results/classifier/118/all/685096 @@ -0,0 +1,364 @@ +permissions: 0.990 +debug: 0.989 +semantic: 0.985 +performance: 0.981 +register: 0.981 +graphic: 0.979 +arm: 0.978 +architecture: 0.978 +device: 0.977 +assembly: 0.974 +PID: 0.971 +kernel: 0.969 +network: 0.968 +boot: 0.966 +peripherals: 0.956 +KVM: 0.954 +files: 0.952 +vnc: 0.952 +user-level: 0.949 +ppc: 0.948 +socket: 0.942 +mistranslation: 0.927 +risc-v: 0.919 +VMM: 0.916 +hypervisor: 0.910 +virtual: 0.905 +TCG: 0.889 +x86: 0.784 +i386: 0.360 + +USB Passthrough not working for Windows 7 guest + +USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest. + +The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place. + +I am trying this with the latest git-pull of QEMU-KVM. + +The command line to launch qemu-kvm for win7 is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150 + +The command line to launch qemu-kvm for winxp is: +sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150 + +Any help is appreciated. + +I suffer from the same issue using QEMU 1.1. I tried 5 different USB thumbdrives and none of them worked. Interesting was that a USB 1.1 mouse was working though. + +Same problem here, using: +qemu-kvm 0.13 +kernel 2.6.36.2 +kvm-intel + +Guest: +Windows 7 Enterprise x64 + +INFO USBHOST: + Device 2.2, speed 480 Mb/s + Class 00: USB device 054c:02a5, Storage Media + +INFO USB: +Device 0.3, Speed 480 Mb/s, Product Storage Media + +Device appears in Windows 7 but in Error Code 10. + + +Ugh... I have just realized that KVM only supports UHCI, so not USB 2.0 support + + +two years passed... nothihg changed.... +qemu 0.14.1+win7(32/64) the problem persist + +Just found this problem with Win7 guest, both 32 and 64-bit, using qemu-kvm 1.01. WinXP is absolutely fine. + +How can this /possibly/ not be a priority to fix? + +This is an issue for me with Win7 SP1 64-bit guest on Ubuntu 12.10 (qemu-kvm 1.2.0+noroms) + +Waiting on a microsoft license, hoping to be able to test this in the next 2 weeks. + +This is also affecting Windows Server 2008 and happens with all usb storage devices I tested. + +Bug #1033727 is specifically about qemu-kvm 1.2.0 and higher, see comment #8 on that bug for example. This bug is about earlier versions, including the version in 12.04 LTS. + +This maybe not a duplicate as we're using 1.3.1 and Windows 7 isn't working there either. All other Operating systems are working though. + +@Wessel: I believe the bug you pointed out as duplicate is saying that USB passthrough isnt working on any guest OS, but this bug is specifically targeted about Windows 7 not working. + +I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate. + +Lol weird it's not marked as duplicate anymore anyway, guess it was not you then. Don't know what happened. + +Can this bug be fixed in KVM or is it really to Windows specific? Else I may have a look at it, never did any KVM development though, should be fun. + +@Serge: Did you get the license already and had a look at this bug? + +@Sam, + +I have the license now, but haven't had a chance to reproduce yet, sorry. It's on my list. + +Upstream git head still gives me this problem, as does back to 0.14.0. + +Note however that the same qemu builds, with the same usb stick, work fine using a linux guest. + +The same stick, inserted to the same windows version on native hardware also works. + +So it's not bad hardware, it's not hardware unsupported by windows, and qemu *is* passing the usb device through sufficiently that windows SHOULD be able to make use of it. + +So this appears to be something specific that windows wants. + +I've seen mention of windows registry tricks involving removal of top and bottom filters for the device... I haven't tested that to see if that would be a workaround. + +Is there any workaround? + +We're currently evaluating different RTOS systems. One is Linux RT with KVM/QEMU with Windows 7. This bug breaks the latency measurement setup and Linux RT is out of race. It there anyway to fix the issue? + +Hi Jens, + +could you tell us exactly what you are trying to pass through, what commands you've tried, and with what version of qemu (and, if hand-built, which options were passed to configure). + +1.5 came with a new passthrough implementation, but alongside the old. So I wonder whether choosing the libusb based implementation would help. + +Hi Serge, + +for your information. I sent a mail to the devel mailing list. See below. + +I've tried to passthrough special Vector automotive usb in house devices. +Look here: http://vector.com/vi_vn1600_en.html. + +What do you mean with "what commands you've tried"? + +I've tried three QEMU versions: + +1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0) +2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0) +3. Hand builded QEMU 1.6.1 with standard configure call + $ ./configure --prefix=/opt/kvm && make -j + +Next, I want to build qemu from git? + +I use virt-manager or virsh to start/stop my guest. The QEMU command line is: + +qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc- +i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1 +-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults +-chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime +-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 +-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive +file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id +=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive- +sata0-0-0,id=sata0-0-0,bootindex=1 -netdev +tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net- +pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3 +-chardev pty,id=charserial0 -device isa- +serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc +127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 +-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb- +host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon- +pci,id=balloon0,bus=pci.0,addr=0x5 + + +Mail to devel list: + +Hi all, + +we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, etc.). +One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all +works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU bug +breaks my measurement setup and evaluation. + +I've some usb devices for the Windows 7 guest. I configure them as USB passthrough. +The devices appears in the device manager of Windows 7, but with +"Error code 10": device cannot start". The Windows driver fails on USB set configuration. +The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL fails with +invalid parameter. + +driver log: +00000009 0.65470564 vnCDrvUsbControlRequestSetConfiguration, WdfUsbTargetDeviceSelectConfig single interface failed 0xc000000d +00000010 0.65472370 vnCDrvUsbIFPrepareHardwareState, vnCDrvUsbControlRequestSetConfiguration failed: 0xc000000d +00000011 0.65473646 vnCDrvDevConPrepareHardware, vnCDrvUsbIFPrepareHardwareState failed 0xc000000d +00000012 0.65474838 vnCDrvEvtDevicePrepareHardware, vnCDrvDevConPrepareHardware failed 0xc0000001 +00000013 0.6547 + +This bug breaks my latency measurement setup and Linux RT is out of the evaluationg +race. Windows CE should not win :-), it there anyway workaround or hack to fix the issue? + +My setup: + +Ubuntu 64-bit +Windows 7 Embedded Guest +Linux Kernel: 3.10.10-rt7 +QEMU: 1.4.0, 1.6.1 + +thanks, +Jens + + +All devices work on other hypervisors like VMware Workstation etc... + +I have the same problem. I tried it with qemu 1.4 and the last 1.6.0-dfsg-2 on a debian testing system. Win 7 says always "This device cannot start. (Code 10)". I tried a lot of usb sticks but always the same... +I hope there will be sometime a solution for this :( I wait over a year in the hope that this will work. + +I also have this issue. USB pass-through didn't work on windows 8. I try to use "virt-mamanger", and set USB interface to USB 2.0. Then everything works well. The default one would be USB 1.0. + +I don't know how to transform virt-manager's configuration to QEMU's command line arguments. Hope this help. + +@FanFan, + +if you start such a vm and do 'ps -ef | grep kvm' should see the kvm command line which is working for you. + +I think you should appoint the usb bus which according to your usb type, such as: +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 + -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 + -device usb-hub,id=hub0,bus=usb.0,port=2 + -device usb-tablet,id=input0,bus=usb.0,port=1 + -device usb-host,hostbus=2,hostport=2,id=hostdev0,bus=usb1.0 + +Hi, I had the same problem. Tested a lot. My solution to passthrough usb devices to a windows 7 x64 guest: + +parameter part: + +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0 + +I also tried the device +piix4-usb-uhci + +instead of usb-ehci + +piix4-usb-uhci caused the Code 10 error in the windows device manager. + +lsusb will give you a list of plugged in usb devices. eg. + +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + +1d6b:0002 +and +1d6b:0003 + +are vendorid:prouctid + +replace {} with the ids and it should work. I tested it with + +- ssd usb 3.0 drive +- retail usb seagate usb 2.0 hdd drive. + +followup: + +my understanding is there are a bunch of usb interfaces: + +uhci is usb 1.0 +ehci is usb 2.0 +xhci is usb 3.0 +… + +-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 is insufficent for modern usb devices so windows errors with code 10. ehci have enough to bring full support for modern usb devices. + +qemu is like LEGO where you can wire it all together :-) + +refference: +https://github.com/qemu/qemu/blob/master/docs/usb2.txt +https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Quoting Manuel Baesler (<email address hidden>): +> followup: +> +> my understanding is there are a bunch of usb interfaces: +> +> uhci is usb 1.0 +> ehci is usb 2.0 +> xhci is usb 3.0 +> … +> +> -device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 +> is insufficent for modern usb devices so windows errors with code 10. +> ehci have enough to bring full support for modern usb devices. +> +> qemu is like LEGO where you can wire it all together :-) +> +> refference: +> https://github.com/qemu/qemu/blob/master/docs/usb2.txt +> https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB + +Thanks - so (this isn't documented in the qemu man page) am I to assume +that given " -usbdevice host:0781:5150" as the original bug submitter is +doing means "give me usb 1.0" ? + +Max, does it work for you if you use (...taking a wild guess) : + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +or perhaps + + -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \ + -usbdevice tablet \ + -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0 + +You also might try xhci in place of ehci. + +(If this does turn out to be the answer, then the bug title should be +changed to include 'usb2.0 and usb3.0 devices', to aid people in +finding this gem in the future) + + status: incomplete + + +RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device: + +00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) + +I can connect to network with qemu 2.0 with and win 7 pro 64bit guest. + +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x0b95,productid=0x772b,id=hostdev0,bus=usb.0 -usb -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Bus 007 Device 014: ID 0b95:772b ASIX Electronics Corp. + + +Unfortunately there is lack of automation and documentation. Ideally you would use something like +qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -usb2 -usbdevice host:0b95:772b -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c + +Tthe usb device info from Linux should be enough to determine if the device is to be connected to usb1 or usb2, right? + +So the RightWay(tm) to fix this is to download http://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD + +and run + +qemu-system-x86_64 -net none -readconfig ich9-ehci-uhci.cfg -device usb-host,vendorid=0x0b95,productid=0x772b -device usb-tablet <extra options here> + +Thanks Michal, + +so at sounds like at least that file should be distributed with the qemu package. I don't know the best place for that, or how cleanly we can integrate it to make it easiest on the end-user... + +Actually, in qemu 2.0.0 the file is packaged. However, it is packaged in the qemu package rather than qemu-system package so users are unlikely to have the file. + +The file seems to be in qemu-system-common (at least in Ubuntu 14.10). + +The next question is how to best help the user to run the right command. Should it go into the manpage? + +Comment No. 23 by Manuel Baesler worked for me in Windows 10. +lsusb gave me: +Bus 001 Device 040: ID 8564:1000 Transcend Information, Inc. JetFlash +Qemu Flags used: +-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x8564,productid=0x1000,id=hostdev0,bus=usb.0 + +The only way to see my iPhone (or any USB device) in the Windows guest is to have it redirected via "Spice", not with libvirt xml capture elements. + +Select Redirect USB device in virt-viewer and it just works. + +I have upgraded to Qemu 2.4, libvirt 1.2.21 and upgraded the qemu machine to "q35" as I tried hard to make it work via xml. +Now that I have it working, I don't plan to check if it works with less current software / machines. + +If I get the previous comments right, this is just about using the right configuration, and not a real bug? If so, I assume we can close this ticket nowadays? + +Closing this bug for QEMU, since there haven't been any replies within the last 7 months. + +Also marking the ubuntu task as incomplete. It looks like it's sorted, but let's give it some time for people to comment if they still have an issue. + +Doing the same for the debian task, which doesn't have an upstream bug anyway. + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + |