> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Tuesday, April 05, 2011 1:39 AM > To: CAI Qian > Cc: John Youn; Paul Zimmerman; Alan Stern; linux-usb@xxxxxxxxxxxxxxx; Don > Zickus; Xu, Andiry > Subject: Re: [RFT] usbcore: Bug fix: system can't suspend with USB3.0 > device connected to USB3.0 hub > > On Sat, Apr 02, 2011 at 04:35:17AM -0400, CAI Qian wrote: > > Hi Sarah, > > > > After applied this patch on the top of USB3 hub changes patches in my > branch (can also reproduce the original problem), the problem is still > existed. > > > > Freezing user space processes ... (elapsed 0.01 seconds) done. > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > > PM: Preallocating image memory... done (allocated 3924380 pages) > > PM: Allocated 15697520 kbytes in 2.53 seconds (6204.55 MB/s) > > hub 8-1:1.0: suspend error -16 > > pm_op(): usb_dev_freeze+0x0/0x20 returns -16 > > PM: Device 8-1 failed to freeze: error -16 > > So I think the 8-1 device is your roothub. There's a couple different > places the code could return -EBUSY (which is what -16 is). > > In xhci-hub.c, there's > > if (hcd->self.root_hub->do_remote_wakeup) { > port_index = max_ports; > while (port_index--) { > if (bus_state->resume_done[port_index] != 0) { > spin_unlock_irqrestore(&xhci->lock, flags); > xhci_dbg(xhci, "suspend failed because " > "port %d is resuming\n", > port_index + 1); > return -EBUSY; > } > } > } > > There's also various places in the USB core on the device, bus, and host > controller suspend patch that can return -EBUSY. Can you enable > CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING and give me the dmesg > output after you run `dmesg -n 8`? > > That will allow me to see if the bus suspend function in the xHCI driver > is failing. If so, that could indicate something is wrong with the > resume_done handling with the new split roothub code. > > I'm wondering if you're running into an issue I had trouble reproducing. > I thought there might be an issue with resume_done in the xHCI code, but > Andiry Xu and Alan Stern convinced me my reasoning had to be wrong about > the cause of the bug, so I never included the bug fix patch in the final > patchset. The patch is attached. The patch only fixes the resume_done > issue for a high speed hub, but I could either modify the patch to work > for USB 3.0 hubs, or perhaps your resume_done issue is with the high > speed portion of your USB 3.0 hub. > > If, after you enable xHCI debugging and try to hibernate the system, you > see a message from the xHCI driver about a particular port resuming, > then try to apply that patch and see if it allows you suspend. > > > Restarting tasks ... done. > > > > Unfortunately, the latest Linus tree had a regression that prevent > hibernate/resume from working even without those patches. > > CIA, what host controller are you running under? What brand of hub are > you using? > > Andiry, you said the simpler patched allowed your system to suspend and > hibernate. Which host are you using? Which hub? > I've tested the patch on the xHCI controller on the AMD Hudson platform and a NEC uPD720200 external host controller. The hub is Buffalo BSH4A03U3 USB3.0 hub. The devices I used are Buffalo HD-HXU3 USB3.0 1TB drive and Western Digital WDBACW0010HBK-SESN USB3.0 1TB drive. The patch works for both xHCI controllers in system suspend. I have not tested system hibernation because my system cannot hibernate with the usb-next branch, even without xhci-hcd loaded. I've not got time to look into that. Thanks, Andiry -- 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
