Re: High-Impact: xhci_hid - "Not enough bandwidth for new device state"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 23, 2019 at 03:12:53PM +0200, Frank Bergmann wrote:
> Hi Greg,
> 
> 
> Thank you for answering! You are my hero.
> 
> 
> > not much to be done [...] bandwidth
> > [...] we can't do the impossible here
> 
> 
> It is not the bandwidth! That would be easy...
> 
> 
> 1. USB 3.0 on my Dell XPS 15 9370 has 10GB/s, that's enough for a Webcam
> (USB 2.0) plus some audio...

Are you sure?  It all depends on what that devices are asking for.
Remember USB 2 devices suck the bandwidth of a USB connection like a
starving sponge.

> 2. It works after a reboot for a while, if I first add the Webcam and
> then(!) start the VM (VMware Player or Workstation 15)

It depends on the order in which you ask for resources.

I have no idea what vmware does, and how it is faking all of this out by
possibly using kernel drivers or userspace interactions.  So I wouldn't
use that as an example of anything working well :)

> 3. It worked in Windows 7 and Windows 10 (WebCam plus audio from VMware
> Player (Windows versions)) before I switched to Ubuntu 18.04.

Windows 7, like older versions of Linux, would not try to calculate the
bandwidth requirements ahead of time, and would just try to work.  That
causes problems with dropped packets and other fun issues.  Linux solved
this in newer releases by doing the calculations "up front" and you are
seeing the result.  You always were going over the max limit, but when
using the device, "getting lucky".

I think Windows 10 also does what Windows 7 did, but am not quite sure.
Try asking on a Windows list...

> 4. RedHad guys acknowledged the bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1411604
> 
> 
> > Many people have that configuration
> 
> 
> Please search Google for 'USB "Not enough bandwidth for new device state"'.
> You will find 650 results with quite specific and similar error
> descriptions.

It all comes down to the configuration of your devices and root hubs and
controller.  Yes, lots of people can duplicate this issue, but then
again, that's why we put the check in there, to give people a chance to
understand why things would later stop working.

> The bug seems to occur in the isochronic transmission part of USB 3.0.
> Somebody suspected it occurs if there are two devices trying to transmit at
> the same time (WebCam + VM audio).

Probably.

> > separate USB hub
> 
> 
> Already tried that and zillions of other combinations. In particular I tried
> with no USB hub at all, just WebCam + VM and no other hardware.

Root hub.  The device that connects the PCI device to the USB bus.  On
some laptops there is one root hub per USB port, on others, only 1 root
hub for all plugs together.  It depends on your system.  If you have a
desktop system, try plugging in a new PCI USB controller, that is a root
hub device.

> After downgrading to USB 2.0 via BIOS it worked, though... But that's not
> possible for other reasons.

Yes, that is a normal solution as then your USB 3 devices do not ask for
"too much" bandwidth.  There's also issues with having to reserve ahead
of time the max bandwidth possible for a 2.0 device on a 3.0 bus that
causes problems as you can see.

It's not a simple problem and is always easier to just get a different
USB controller as you will end up having issues on other operating
systems as well, if they don't try to do the reservations ahead of time,
it's just harder to notice.

sorry,

greg k-h



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux