Re: [PATCH] xhci: Calculate old endpoints correctly on device reset
On Mon, Jul 20, 2015 at 04:38:16PM +0300, Mathias Nyman wrote: > > I remember there was an issue about something eating bandwidth as > suspend/resume > that never got fixed? > > here it is: > http://marc.info/?l=linux-usb&m=141561758015676&w=2 That sounds like the same problem (s/w bandwidth check failing on a new TT, even though the only change in the system is suspend and resume). I'm not sure why the problem would disappear later on, though, but I suppose it would be sensitive to what kind of devices are attached. > Not sure if Kenneth has triggered it lately? > > Anyways, patch looks good, I'll send it forward Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: Calculate old endpoints correctly on device reset
When resetting a device the number of active TTs may need to be
corrected by xhci_update_tt_active_eps, but the number of old active
endpoints supplied to it was always zero, so the number of TTs and the
bandwidth reserved for them was not updated, and could rise
unnecessarily.
This affected systems using Intel's Patherpoint chipset, which rely on
software bandwidth checking. For example, a Lenovo X230 would lose the
ability to use ports on the docking station after enough suspend/resume
cycles because the bandwidth calculated would rise with every cycle when
a suitable device is attached.
The correct number of active endpoints is calculated in the same way as
in xhci_reserve_bandwidth.
Signed-off-by: Brian Campbell
---
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7da0d60..526ebc0 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3453,6 +3453,9 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd,
struct usb_device *udev)
return -EINVAL;
}
+ if (virt_dev->tt_info)
+ old_active_eps = virt_dev->tt_info->active_eps;
+
if (virt_dev->udev != udev) {
/* If the virt_dev and the udev does not match, this virt_dev
* may belong to another udev.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB devices disappering on resume on pantherpoint chipset with dock
Hi, On Wed, Nov 19, 2014 at 05:04:27PM +0200, Mathias Nyman wrote: > > 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. Unfortunately it doesn't seem to make any difference, the bandwidth drops at the roughly the same rate. (I've put the logs at http://www.z273.org.uk/tmp/2014-11-19+hack/) Brian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB devices disappering on resume on pantherpoint chipset with dock
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 :00:14.0: Recalculating BW for rootport 3 [ 205.933360] xhci_hcd :00:14.0: Final bandwidth: 27, Limit: 1607, Reserved: 322, Available: 78 percent [ 409.192473] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 409.192475] xhci_hcd :00:14.0: Final bandwidth: 402, Limit: 1607, Reserved: 322, Available: 54 percent [ 447.874989] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 447.874991] xhci_hcd :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 :00:14.0: Recalculating BW for rootport 3 [ 467.998689] xhci_hcd :00:14.0: Final bandwidth: 1152, Limit: 1607, Reserved: 322, Available: 8 percent ... [ 469.592653] xhci_hcd :00:14.0: Adding 1 ep ctxs, 11 now active. [ 469.592655] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 469.592656] xhci_hcd :00:14.0: Not enough bandwidth on HS bus for newly activated TT. [ 469.592657] xhci_hcd :00:14.0: Removing 1 failed ep ctxs, 10 now active. [ 469.592658] xhci_hcd :00:14.0: Not enough bandwidth [ 469.592659] xhci_hcd :00:14.0: xhci_reset_bandwidth called for udev 880210693800 [ 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 :00:14.0: Recalculating BW for rootport 3 [ 492.742796] xhci_hcd :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. Cheers, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
