On Sat, 29 Jan 2011, Paul Bender wrote:
> > Below is a diagnostic patch you can try out. Please
> > apply it to a vanilla kernel (i.e., without your own patch) and enable
> > CONFIG_USB_DEBUG. Then post the dmesg output showing what happens
> > during a pair of suspend attempts.
>
> Thank you for the patch. I have attached files for good (suspend to RAM
> succeeds) and bad behavior (suspend to RAM aborts)
Good. The log files indicate that there was indeed a race: A wakeup
request was received after a resume had started but before it had made
any progress. It also explains the alternating behavior; waking up the
root hub cleared the flag that prevented the controller from
suspending, so the next suspend worked okay.
I think the patch below will solve the problem. The idea is not to
clear the WAKEUP_PENDING flag until after the resume is complete.
Alan Stern
Index: usb-2.6/drivers/usb/core/hcd.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -1955,7 +1955,6 @@ int hcd_bus_resume(struct usb_device *rh
dev_dbg(&rhdev->dev, "usb %s%s\n",
(msg.event & PM_EVENT_AUTO ? "auto-" : ""), "resume");
- clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags);
if (!hcd->driver->bus_resume)
return -ENOENT;
if (hcd->state == HC_STATE_RUNNING)
@@ -1963,6 +1962,7 @@ int hcd_bus_resume(struct usb_device *rh
hcd->state = HC_STATE_RESUMING;
status = hcd->driver->bus_resume(hcd);
+ clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags);
if (status == 0) {
/* TRSMRCY = 10 msec */
msleep(10);
--
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
