On Mon, 14 Feb 2011, Dirk Hohndel wrote:
> > It might help to see the dmesg output rather than the system log file.
> > Include everything going back to the boot.
>
> Here's the latest, with the latest kernel from Linus: 2.6.38-rc4-00178-g795abaf
> which includes the commit that you mentioned bf3d7d40e42a85ca73a34e1385ff34f092a384eb
>
> I did a successfull suspend / resume while the system was in the docking
> station - that's around seconds 42-44 in the dmesg output.
>
> Next I undock and do another suspend attempt - starts around second
> 57. This one failed again, but now we have much more information from
> the dmesg output - attached all the way from reboot.
>
> > > 1-1 appears to be my built-in root hub.
> >
> > No, the root hub is usb1. 1-1 is the device plugged into port 1 of the
> > root hub. If you have a debugfs filesystem mounted, you can see the
> > device list in /sys/kernel/debug/usb/devices.
>
> I'm attaching that as well :-)
>
> Let me know what else I should send / try.
Okay, this is great. The log shows you have a Broadcom Bluetooth
device that got disconnected right at the same time each suspend
started. Did you unplug it by hand or were the disconnects triggered
by the hardware somehow?
At any rate, the close timing between the disconnect and the suspend
caused a new race to show up, one I haven't come across before. Even
though the Bluetooth device's USB port was disabled, the device was not
yet unregistered. The hub driver saw the device structure was still
present and refused to suspend, thinking there was an unsuspended child
device attached.
I can't recall having seen this particular failure path (an attempt to
suspend a hub while one of its attached devices is still active) in
years, if ever. Hence the easiest way to solve the problem is to
remove the check. Hopefully the patch below will fix your problem.
Alan Stern
P.S.: Contrary to Linus's earlier suggestion, it's not a good idea to
remove _all_ checks for failures during suspend. The same code is used
for both system sleep and runtime PM, and we definitely _do_ want to
catch failures during runtime suspend.
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
@@ -2457,21 +2457,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__);
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
