Description of problem: virt-viewer prints an error dialog when connecting an USB device to a guest (while no drivers are already installed on Windows client). The dialog remains desplayed until OK button is pressed. The USB device is mostly connected to the guest but the error dialog remains which is confusing for users. Version-Release number of selected component (if applicable): usbclerk-win-0.1-3 + patch solving removal of winsusb driver - dealing with VID:PID format. mingw-virt-viewer-0.5.3-8.el6 Client: Windows7 Guest: RHEL6 How reproducible: Always Steps to Reproduce: 1. Be sure you have an Windows client and USB device which was never plugged into the client (or has no drivers installed on the client) 2. Be sure USB clerk service is running. 3. Connect to the guest with remote-viewer client and grab focus. 4. Plug USB device to the guest. Actual results: Error dialog is prompted: USB redirection error: Could not auto-redirect Kingston Technology Device [0951:162d] at 1-3: Device was not found Expected results: No error dialog Additional info: remote-viewer stdout: libusbx: warning [windows_get_device_list] could not retrieve port number for de vice '\\.\ROOT#SYSTEM#0001', skipping: [13] The data is invalid. libusbx: warning [windows_get_device_list] could not retrieve port number for de vice '\\.\ROOT#SYSTEM#0001', skipping: [13] The data is invalid. (remote-viewer.exe:1472): GSpice-WARNING **: failed to create a named pipe to us bclerk (231) All pipe instances are busy. (remote-viewer.exe:1472): GSpice-WARNING **: win usb driver install failed -- Fa iled to create named pipe (231) All pipe instances are busy.
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. ***