Bug 824535

Hi,

(In reply to comment #0)
> Description of problem:
> While testing USB-Redirection of a WebCam for a Windows Guest (Both Windows
> XP 32, and Windows 7 64), the WebCam is not usable on the guest after
> connecting using remote-viewer.  
> 
> The Error that shows up on the terminal is (This happens when any type of
> playback from the webcam is attempted): 
> (remote-viewer: 8730): GSpice-CRITICAL **: usbredirhost error: submitting
> iso transfer on ep 81: -1, stopping stream.
> libusb:error [submit_iso_transfer] submiturb failed error -1 errno=28

errno = 28 is ENOSPC, this means that there is not enough free / available USB bandwidth. Normally when the OS (which does bandwidth management) reports this error to a driver, the driver will try to fallback to a lower bandwidth setting.  But with virtualization the guest OS is not aware of any non redirected USB users, so this does not work.

Possible reasons for not having enough bandwidth is:
1) Using a USB 1 device in a USB 2 hub
2) Having multiple USB 1 devices on the same bus

Please try plugging the webcam directly into the machine (so don't use a hub), and to not have any
other devices on the same bus. lsusb on the client will show you which devices share the same bus.

Regards,

Hans

Hi Hans,

I was doing all my usb testing with the same ports, and all my other USB tests passed successfully.  Looking at what you suggested, I looked at what I had on my system, 2 buses, and I was connecting both onto the same bus.  My wireless keyboard/mouse reciever was a usb 2.0 device (bus 1) and the usb webcam was a 1.1 device on (bus 2).

So, I switched the USB 1.1 webcam to be on a bus by itself, and the client did see the webcam and I was able to see the what the webcam was currently capturing.  Taking pictures worked fine, and displaying the current capture worked fine, but when I selected Record, I would get a similiar error:

Windows XP:
(remote-viewer: 2414): GSpice-CRITICAL **: usbredirhost error: submitting
iso transfer on ep 83: -1, stopping stream.
libusb:error [submit_iso_transfer] submiturb failed error -1 errno=28

So the difference from before is the line number of the error changed from 8730 to 2414, and ep 81 to ep 83.  

Windows 7:
Same behavior a different line for the error

(remote-viewer:4474): GSpice-CRITICAL **: usbredirhost error: submitting
iso transfer on ep 81: -1, stopping stream.
libusb:error [submit_iso_transfer] submiturb failed error -1 errno=28

If I tried it the other way, webcam on bus2 and keyboard/mouse receiver on bus1, the whole system reboots (client/host).

(And again, I had no issue with testing any other usb devices: optical drive, smart card reader, mouse, keyboard, headset)
-Vimal

I tried it again webcam on bus2 (by itself) and the keyboard/mouse receiver on bus1.  Right when I plug in the webcam the vm freezes and reboots (100% reproducible).  I have looked for coredumps (don't see any).  I will look take a look into the logs to see what information I can find.  I tried other usb devices with the same setup and a headset also got the machine to reboot (but a mass storage device worked fine).

Can you please do an "lsusb -v > log" with the webcam in question plugged in, and attach the generated log file here? Thanks, Hans.

Created attachment 586896 [details]
Log of lsusb -v With Logitech WebCam attached.

Thanks for the log, but the webcam does not show in there. Can you please plug the webcam into the client machine without using usb-redir, regenerate the log file, and attach the new log file?

Created attachment 587397 [details]
USB log with Logitech Webcam attached

Tested again with an updated version of spice-server (spice-server-0.10.1-10.el6.x86_64).  The machine rebooting is not seen anymore.  The webcam works when it is by itself, except for when recording is attempted, then seeing the same errors: GSpice-CRITICAL **: usbredirhost error: submitting
iso transfer on ep 81: -1, stopping stream.
libusb:error [submit_iso_transfer] submiturb failed error -1 errno=28, and the client/host froze.

The only log I could find:
/var/log/libvirt/libvirtd.log:

2012-05-31 17:48:31.414+0000: 2794: info : libvirt version: 0.9.10, package: 18.el6 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2012-05-09-04:01:41, hs20-bc2-5.build.redhat.com)
2012-05-31 17:48:31.414+0000: 2794: warning : virKeepAliveTimer:182 : No response from client 0xfc14f0 after 5 keepalive messages in 30 secon

Looking at yuor lsusb output yoo're testing with an sandy bridge machine. sandy bridge chipsets no longer have the standard usb setup of an EHCI controller with UHCI companion controllers. Instead they only have an EHCI controller and a build in USB-2 HUB for USB-1 compatiblity.

This means that you're in essence using the USB-1 webcam you're testing with through a USB-2 hub. And unfortunately the Linux kernel USB scheduling code cannot handle USB-1 isochronous traffic running over a USB-2 hub very well.

When you're trying to record, windows presumably also tries to start an audio stream from the webcam's mic. 

This causes 2 isoc streams to be active at the same time, and the Linux kernel EHCI driver USB scheduling code runs out of bandwidth while trying to schedule the 2nd stream. This causes a errno=28 error on the Linux client side, which gets translated to an IO-error to the guest OS, at which point the guest hangs,
so we have 2 problems here:
1) The guest hangs on an UI error -> cannotfix
2) The Linux kernel EHCI driver USB scheduling code is suboptimal, you could try opening a bug against the kernel for this, but chances of getting this fixed are pretty low, as this has been known for a very long time now ...

Given that neither issue is a usbredir bug I'm going to close this as notabug, which should be interpreted as not an usbredir bug. It does trigger a known kernel issue, for which you could file a new bug against the kernel if you want...