Bug 842816
Summary: | virt-viewer prints an error dialog when connecting an USB device to a guest (while no drivers are already installed on WIndows client) | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Marian Krcmarik <mkrcmari> |
Component: | mingw-virt-viewer | Assignee: | Uri Lublin <uril> |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.1.0 | CC: | acathrow, adevolder, agilboa, dblechte, iheim, jbiddle, marcandre.lureau, vipatel |
Target Milestone: | --- | ||
Target Release: | 3.2.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | spice | ||
Fixed In Version: | mingw-virt-viewer-0.5.3-24.el6ev | Doc Type: | Bug Fix |
Doc Text: |
Previously, on Windows 7 clients, plugging in a USB device when the guest display was in focus would cause an error message stating "USB redirection error: Could not auto-redirect Kingston Technology Device [0951:162d] at 1-3: Device was not found", even though the device was being correctly passed to the guest machine. Now, the way USB devices are recognised has been changed, so they can be passed to the guest without errors.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2013-06-10 19:58:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Spice | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marian Krcmarik
2012-07-24 16:12:59 UTC
Uri, please have a look. USB Clerk log: 1756::INFO::2012-07-24 19:03:27,890::USBClerk::dispatch_message::Installing winusb driver for 0951:162d 1756::INFO::2012-07-24 19:03:27,896::USBClerk::install_winusb_driver::Looking for device vid:pid 0951:162d 1756::INFO::2012-07-24 19:03:27,896::USBClerk::install_winusb_driver::Device 0951:162d found 1756::INFO::2012-07-24 19:03:27,896::USBClerk::install_winusb_driver::Installing driver for USB device: "DataTraveler 102" (0951:162d) inf: usb_device_0951_162d.inf 1756::INFO::2012-07-24 19:03:29,695::USBClerk::install_winusb_driver::Another driver is installing, will retry every 2000ms, up to 10 times 1756::INFO::2012-07-24 19:03:38,611::USBClerk::dispatch_message::Completed successfully still under investigation, no time for 3.1, propose to 3.2 I did not reproduce the bug exactly as in comment 0 but, It seems that libusb_get_device_address() may be inconsistent across (before/after) WinUSB driver install. It seems that libusb_get_port_number() is consistent across WinUSB driver install. I suspect that the scenario is as follows: 1. A USB device is being redir'ed (in comment 0 step 4 with auto-share) - Lets assume its bus.address is now 4.1 2. The WinUSB driver is installed - Lets assume its bus.address is now 4.2 including removal of device 4.1 and insertion of device 4.2 3. spice-gtk tries to redir device 4.1. - that fails due to device-not-found Possibly during step 2 spice-gtk gets events for removal of device 4.1 and insertion of device 4.2, which follows with 4. spice-gtk tries to redir device 4.2 5. The USB device is shared with the guest. I replaced calls to libusb_get_device_address with calls to libusb_get_port_number and made a scratch build: https://brewweb.devel.redhat.com/taskinfo?taskID=5460053 Marian can you test if that scratch-build solves the problem ? (In reply to comment #4) > > I replaced calls to libusb_get_device_address with calls to > libusb_get_port_number and made a scratch build: > https://brewweb.devel.redhat.com/taskinfo?taskID=5460053 Hans revealed a weakness of this solution, basically nack'ing it. > Marian, can you test if that scratch-build solves the problem ? Would be nice to know if it does solve the problem, but we have to come up with a different fix anyway. Trying a different solution -- on Windows client identify USB devices by vid:pid instead of by bus.address Of course vid:pid is consistent across WinUSB driver installation. Using two devices with the same vid:pid on the same Windows client is already not supported, since Windows install USB drivers for specific devices based on their vid:pid Patches sent upstream http://lists.freedesktop.org/archives/spice-devel/2013-March/012835.html Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-0889.html *** Bug 868338 has been marked as a duplicate of this bug. *** *** Bug 969544 has been marked as a duplicate of this bug. *** |