Hi On 19.11.2014 01:03, Brian Campbell wrote: > Hi, > > I'm having trouble with USB devices connected to a Thinkpad X230's dock > disappearing after a few suspend/resume cycles. Devices connected directly to > the laptop rather than the dock are not affected. The main symptom in the > logs is a complaint about bandwidth, and comes from the bandwidth checking > code in the xhci driver that is only used for Intel Pantherpoint chipsets, as > far as I can tell. > > To give a controlled example, I booted the laptop running 3.17.1 with extra > xhci logging, filled up the USB sockets on the dock with a flash drive, a > keyboard and a couple of mice, then suspended and resumed it until the > keyboard stopped working. Through the first two suspends everything works, > but the reported bandwidth changes: > > [ 205.933357] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 205.933360] xhci_hcd 0000:00:14.0: Final bandwidth: 27, Limit: 1607, Reserved: 322, Available: 78 percent > > [ 409.192473] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 409.192475] xhci_hcd 0000:00:14.0: Final bandwidth: 402, Limit: 1607, Reserved: 322, Available: 54 percent > > [ 447.874989] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 447.874991] xhci_hcd 0000:00:14.0: Final bandwidth: 777, Limit: 1607, Reserved: 322, Available: 31 percent > > (It also reports bandwidth for some individual ports, but these don't change.) > On the third resume it changes again, then later complains about the mice: > > [ 467.998687] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 467.998689] xhci_hcd 0000:00:14.0: Final bandwidth: 1152, Limit: 1607, Reserved: 322, Available: 8 percent > ... > [ 469.592653] xhci_hcd 0000:00:14.0: Adding 1 ep ctxs, 11 now active. > [ 469.592655] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 469.592656] xhci_hcd 0000:00:14.0: Not enough bandwidth on HS bus for newly activated TT. > [ 469.592657] xhci_hcd 0000:00:14.0: Removing 1 failed ep ctxs, 10 now active. > [ 469.592658] xhci_hcd 0000:00:14.0: Not enough bandwidth > [ 469.592659] xhci_hcd 0000:00:14.0: xhci_reset_bandwidth called for udev ffff880210693800 > [ 469.592661] usb 3-3.4: Busted HC? Not enough HCD resources for old configuration. > > There are similar messages for another attempt at this mouse, and another pair > for the other mouse. Then on the fourth resume the bandwidth is exhausted: > > [ 492.742794] xhci_hcd 0000:00:14.0: Recalculating BW for rootport 3 > [ 492.742796] xhci_hcd 0000:00:14.0: Final bandwidth: 1277, Limit: 1607, Reserved: 322, Available: 0 percent > > And then the keyboard fails too. > > I originally had the problem with Ubuntu 14.04's stock kernel, so it's been > around for a while, perhaps always. A bug filed with Ubuntu suggests that it > also happens with some Dell machines, too > (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116525). I put more > logs and system details up at http://www.z273.org.uk/tmp/2014-x230-usb-dock/ > in case they're useful to someone. > > Thanks for the detailed logs, and the analysis so far. Looks like we end up with old used bandwidth values after suspend/resume, and then add new bandwidth reserved values on top. I tried to reproduce it myself with a headset and keyboard connected via a usb2 hub to a usb3 port. but wasn't able to reproduce it The logs also show several cases of: [ 470.110821] xhci_hcd 0000:00:14.0:Setup ERROR: setup context command for slot 5. [ 470.110822] usb 3-3.1: hub failed to enable device, error -22 [ 470.370725] xhci_hcd 0000:00:14.0: Resetting device with slot ID 5 [ 470.370728] xhci_hcd 0000:00:14.0: // Ding dong! [ 470.370739] xhci_hcd 0000:00:14.0: Completed reset device command. [ 470.370744] xhci_hcd 0000:00:14.0: Can't reset device (slot ID 5) in default state [ 470.370745] xhci_hcd 0000:00:14.0: Not freeing device rings. One theory would be that when we fail to reset the device because it's already in the default state (state after reset) we end up not freeing the rings, and won't free the reserved bandwith either. If you wan't you could try this hack, just to check the theory. It will free the reserved bandwith event if resetting the device fails. diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 2a5d45b..e655459 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3520,7 +3520,7 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev) xhci_dbg(xhci, "Not freeing device rings.\n"); /* Don't treat this as an error. May change my mind later. */ ret = 0; - goto command_cleanup; + break; case COMP_SUCCESS: xhci_dbg(xhci, "Successful reset device command.\n"); break; -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
