I tried to reproduce this issue on an Intel Ivybridge machine. But I failed.
Kernel version: 4.0.0-rc1 (built against master branch of Greg's usb tree)
USB fabric:
$ sudo lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 5: Dev 3, If 0, Class=Video, Driver=, 480M
|__ Port 5: Dev 3, If 1, Class=Video, Driver=, 480M
|__ Port 6: Dev 4, If 0, Class=Wireless, Driver=, 12M
|__ Port 6: Dev 4, If 1, Class=Wireless, Driver=, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 2: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 11, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 1: Dev 11, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 2: Dev 12, If 0, Class=Hub, Driver=hub/3p, 12M
|__ Port 1: Dev 13, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 1: Dev 13, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 3: Dev 14, If 0, Class=Vendor Specific Class,
Driver=asix, 480M
Test script:
#!/bin/bash
while [ 1 ]
do
echo "devices" > /sys/power/pm_test
sleep 5
echo "freeze" > /sys/power/state
sleep 15
done
I kept this script running for more than 24 hours and didn't see the
issue described below.
Any hints or suggestions?
Thanks,
Baolu
On 2014-11-10 14:40:13, Mathias Nyman wrote:
On 10.11.2014 12:47, Kenneth Johansson wrote:
So I have a problem that happens with 1-2 weeks interval in that the
xhci driver confuses itself and thinks that the usb bus is overused
or something.
The thing is that this is an external usb 2 hub with 7 ports and all
7 is used for different devices. I do a suspend/resume once a day and
thats it.
its the same devices on the hub but the USB driver for some reason
decides that it no longer can allow the devices on the bus.
1. is there any way to reset the entire usb stack without
rebooting?? I run 3.16 ubuntu kernel and I think usb is built in I
at least can see any module named xhci.
2. what can be done to solve this ?? there must be some type of
resource leak here as a reboot solves the problem and I have exactly
the same usb devices that I use.
3. I also notice that we max out at about 30 devices and I think usb
should be able to handle 127.
4. I noticed on a different computer that a usb sound card (5.1) was
also getting the bandwidth error if I attached it to a usb3 hub that
had only that device, it works if I remove the hub.
5. overall usb3 looks to be a bit "unpredictable" and if you google
for this type of errors the advice is to downgrade to usb2. that do
sound like the wrong thing to do unless the xhci hardware is that
broken. is it ? or is this the driver that needs fixing.
-----------------
[65633.315419] usb 3-1.4.1: Product: USB Transfer Cable
[65633.315422] usb 3-1.4.1: Manufacturer: Prolific Technology Inc.
[65633.315607] xhci_hcd 0000:00:14.0: Not enough bandwidth on HS bus
for newly activated TT.
[65633.315612] xhci_hcd 0000:00:14.0: Not enough bandwidth
[65633.315619] usb 3-1.4.1: can't set config #1, error -12
---
[65653.367865] xhci_hcd 0000:00:14.0: Not enough bandwidth on HS bus
for newly activated TT.
[65653.367867] xhci_hcd 0000:00:14.0: Not enough bandwidth
[65653.367872] usb 3-1.2: can't set config #1, error -12
and so on.
--
The xhci controller has a limit for max devices it can support,
usually less than 127.
3.16 kernel and later should report "Max number of devices this xHCI
host supports is %u.\n" when you reach the limit.
I've got reports about bandwidth errors before, so far two different
kinds, one is a context error which happends
while allocating bandwith, and is not really a bandwidth issue. Then
we also got real bandwith errors in cases
when we really shouldn't ave them.
This is one of the many issues I need to address after resolving other
current issues (race in reset endpoint, reset device and stop endoint).
Might be that it's just the driver that needs fixing, need to get my
hands on it. Probably start with displaying more debug output when we
hit bandwidth limits.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
