On Mon, Mar 12, 2012 at 05:46:15PM +0100, Oliver Neukum wrote: > Am Montag, 12. März 2012, 17:22:40 schrieb Sarah Sharp: > > On Fri, Mar 09, 2012 at 04:55:25PM +0100, Oliver Neukum wrote: > > Hi, > > > > I suffer from an S4 problem with XHCI of PantherPoint with rc6. Coming up > > > from S4 I get errors: > > > > > > [ 250.912198] xhci_hcd 0000:00:14.0: setting latency timer to 64 > > > [ 250.912210] usb usb3: root hub lost power or was reset > > > [ 250.912212] usb usb4: root hub lost power or was reset > > > [ 250.912256] xhci_hcd 0000:00:14.0: Slot 1 endpoint 2 not removed from BW list! > > > > Was a USB device connected during this test? > > No device was connected to XHCI. It's been a while since I touched the BW checking code, so I may be confused, but I don't understand how the roothub endpoint got into the bandwidth list in the first place. We should be skipping the roothubs in the bandwidth calculation, and that's what xhci_check_args() does when it's called during bandwidth calculation functions. See the check in xhci_add_endpoint() and xhci_drop_endpoint(). Roothubs aren't real devices, so they shouldn't take real resources. Further, the roothubs don't get a slot ID number. Are you sure there isn't an integrated USB 3.0 or USB 2.0 hub connected between the xHCI host and the port on your laptop? Or perhaps you had a USB device connected at some point in the past and the endpoint failed to be removed from the bandwidth list? Or maybe it's the TT entry for the roothub that's not being removed, and the error message is just misleading... Can you turn on xHCI debugging and send me the full log from boot to the first resume from hibernate? > > > I see the same thing in 3.0 > > > It is interesting that S3 is not affected. It looks like the bandwidth change > > > when going down to S4 is not accounted for. > > > Do you have any ideas? > > > > It may be in how the host controller is being shutdown during hibernate. > > Or maybe the issue is with the xHCI restore state failing on resume, and > > having to assume that the xHCI roothub lost power. Maybe in that case, > > the USB core is not tearing down the previously connected USB devices? > > The root hubs should be treated like hubs. So they go into reset_resume. Ok, I'll take a look at that path. > > Actually, it seems like it should be the xHCI driver's job to tear down > > the bandwidth tables, so the bug is probably in the xHCI driver's resume > > error path. > > I am afraid so. > > > Thanks for finding this bug. I assume you had to hibernate 64 times to > > see the host run out of active endpoint contexts? > > 32 times. We have two virtual root hubs. Yes, this bug takes the better part > of an hour to reproduce. Thank you for being persistent. :) Sarah Sharp -- 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
