On 1/30/2011 1:40 PM, Alan Stern wrote:
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.
Thank you. I applied the patch you provided and it fixed the problem for me.
--
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
