On Tue, Aug 30, 2011 at 04:39:08PM -0400, Don Zickus wrote: > Hi Alan, > > I am trying to dig up an old thread and see what happened to the patch. I > don't have it archived, so I apologize if it doesn't thread correctly. It would probably be polite of me to include a link to an archive. :-) http://marc.info/?l=linux-usb&m=130262401114228&w=2 > > Cheers, > Don > > > On Mon, 11 Apr 2011, Sarah Sharp wrote: > > > On Sun, Apr 10, 2011 at 08:52:13PM -0400, CAI Qian wrote: > > > Hi Sarah, > > > > > > The following was output from the serial console during the second > > > hibernate/resume. Does it help? > > > > > > # echo disk >/sys/power/state > > > PM: Syncing filesystems ... done. > > > Freezing user space processes ... Apr 10 20:46:36 ibm-x3550m3-03 kernel: PM: Syncing filesystems ... done. > > > (elapsed 0.01 seconds) done. > > > Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. > > > PM: Preallocating image memory... done (allocated 313188 pages) > > > PM: Allocated 1252752 kbytes in 0.60 seconds (2087.92 MB/s) > > > hub 9-1:1.0: suspend error -16 > > > > I think Alan said that usb9 or hub 9-0 would be the roothub, so hub 9-1 is > > most likely your VIA hub. The xHCI host was showing up as bus 8 before, > > according to your lsusb output, so on 2.6.39-rc2, the xHCI USB 2.0 > > roothub would still be bus8, and the xHCI USB 3.0 roothub would be bus9. > > So the device that is failing is probably the USB 3.0 portion of your > > VIA hub. Specifically the interface driver is refusing to suspend. > > > > > pm_op(): usb_dev_freeze+0x0/0x20 returns -16 > > > > usb_dev_freeze() attempts to suspend the USB device, eventually calling > > into khubd's suspend method, hub_suspend(). That looks at all the > > children of the hub, making sure that udev->can_submit isn't set for > > each valid usb_device. That will return -EBUSY (-16) if a device is > > active. > > This resembles a problem reported by Dirk Hohndel back around the time > of LinuxConf-Australia. There was no follow-up and the proposed patch > was never submitted. I have included it below so that it can be > tested. > > The idea is that when a device is marked as disconnected, the > can_submit flag doesn't get set to 0. Therefore the test in > hub_suspend() fails, when it ought to succeed. Since that test hasn't > found any serious problems in a long time, the easiest solution was to > remove it. > > Alan Stern > > > > Index: usb-2.6/drivers/usb/core/hub.c > =================================================================== > --- usb-2.6.orig/drivers/usb/core/hub.c > +++ usb-2.6/drivers/usb/core/hub.c > @@ -2478,21 +2478,6 @@ int usb_port_resume(struct usb_device *u > static int hub_suspend(struct usb_interface *intf, pm_message_t msg) > { > struct usb_hub *hub = usb_get_intfdata (intf); > - struct usb_device *hdev = hub->hdev; > - unsigned port1; > - > - /* fail if children aren't already suspended */ > - for (port1 = 1; port1 <= hdev->maxchild; port1++) { > - struct usb_device *udev; > - > - udev = hdev->children [port1-1]; > - if (udev && udev->can_submit) { > - if (!(msg.event & PM_EVENT_AUTO)) > - dev_dbg(&intf->dev, "port %d nyet suspended\n", > - port1); > - return -EBUSY; > - } > - } > > dev_dbg(&intf->dev, "%s\n", __func__); > > > > -- > 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 -- 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
