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
