On Sat, 30 Mar 2013, Matthijs Kooijman wrote: > Hi guys, > > I recently noticed a problem with suspend-to-disk on my Thinkpad X201. > I'm using swsusp, which offers a "press backspace to cancel" while it is > writing out the suspend image to the swap partition. When I do this, the > system mostly recovers, except for the USB ports on my docking station, > which stop working (until I undock and redock again). > > The USB ports on the laptop itself seem unaffected. During a normal > suspend-resume (both to disk and to ram), the ports are also enabled > properly. > > I bisected this problem and it was introduced by the following commit: > > commit c73cee717e7d5da0698acb720ad1219646fe4f46 > Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Date: Wed Oct 31 13:21:06 2012 -0400 > > USB: EHCI: remove ehci_port_power() routine > > This patch (as1623) removes the ehci_port_power() routine and all the > places that call it. There's no reason for ehci-hcd to change the > port power settings; the hub driver takes care of all that stuff. > > There is one exception: When the controller is resumed from > hibernation or following a loss of power, the ports that are supposed > to be handed over to a companion controller must be powered on first. > Otherwise the handover won't work. This process is not visible to the > hub driver, so it has to be handled in ehci-hcd. Are you totally certain about this? I can't see how removing code to change the EHCI port power would make any difference in your case, because the power was on the whole time. > Perhaps there is some code path or set of ports that also need this exception? Not that I can think of. And even if there were, it wouldn't matter in this case because the power level wasn't changed. > I tried reverting this patch on 3.9-rc4 and usb-next, but I got conflicts that > I didn't try to resolve yet. On your system, the only files in the patch that matter are ehci-hcd.c and ehci-pci.c. You could try reverting them alone. Or even just the ehci-hcd.c part, because the one-line change to ehci-pci.c gets used only during probing, not during hibernation. > I've attached the dmesg output from a kernel compiled from usb-next (571bb7a: > Revert "USB: chipidea: add vbus detect for udc") with > CONFIG_USB_DEBUG=y. I booted the kernel and immediately started a > suspend-to-disk (around 50-51s). As soon as the image started being > written to disk, I canceled it and the system resumed (at 52s). These > messages look relevant: > > [ 52.899290] usb 1-1.4: link qh1-0e01/ffff880230cb97c0 start 0 [1/2 us] > [ 52.899345] hub 1-1:1.0: port 5 status 0000.0100 after resume, -19 > [ 52.899347] usb 1-1.5: can't resume, status -19 > [ 52.899348] hub 1-1:1.0: logical disconnect on port 5 Actually the relevant messages are earlier: > [ 52.798212] hub 1-1:1.0: hub_resume > [ 52.798214] hub 2-1:1.0: hub_resume > [ 52.798692] hub 1-1:1.0: port 4: status 0103 change 0000 > [ 52.798819] hub 1-1:1.0: port 5: status 0100 change 0001 > [ 52.799042] hub 1-1:1.0: port 6: status 0503 change 0000 The line for port 5 shows that even though power to the port is on, the docking station's hub has disconnected itself. By contrast, the onboard webcam and bluetooth devices had no problem. > Any idea how to fix this? Do you need any other info? The only thing I can think of is that the 20-ms delay in the ehci_port_power() routine might have made a difference. After reverting the patch, you could try removing everything in that function except the delay. Alan Stern -- 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
