On Thu, Apr 22, 2021 at 01:15:50PM +0200, Greg KH wrote: > On Thu, Apr 22, 2021 at 04:08:13PM +0500, Roman Mamedov wrote: > > Hello, > > > > On Thu, 22 Apr 2021 07:49:38 +0200 > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > Not a bug, this is how USB works. Your first hub really does not have > > > enough bandwidth for that device. Well, we think it doesn't, the > > > calculation for that is really really tricky and we error on the side of > > > "let's not take the risk and just disable the device to be safe". > > > > > > Get a better hub :) > > > > But why the calculation is different when the hub is plugged into the onboard > > USB 2.0 controller -- and there it works? > > You have more hubs in the way, they take up bandwidth on their own just > sitting there. > > > I hope you don't take this as a bug report to make it stop working there as > > well. :) > > > > If it's because the Etron controller is USB 3.0, and the higher speeds are > > somehow accounted for in the bandwidth calculation, that doesn't seem right, > > since both of the plugged in downstream hubs are 1.1/2.0-only. > > USB 2 hubs plugged into a USB 3 controller require horrible things to be > done on the wire to make everything work properly. Part of that > horribleness is bandwidth determination that we honestly are not the best > at in Linux. But again, we err on the side of safety, which means we > guess on the low-end compared to other operating systems. It's even worse in the case of devices plugged into an xHCI controller. Those controllers perform bandwidth allocation automatically in firmware; the kernel doesn't get any say in the matter. With EHCI, the allocation is all done in software. Alan Stern
