On Wed, 26 Jan 2011, Paul Bender wrote: > If you are not the correct person to report this problem to, could you > point me to the correct person. Problems like this should also be posted to the linux-usb mailing list. > I am having a problem in the 2.6.36 and 2.6.37 kernels that I have > traced to kernel commit ff2f078 > <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ff2f078>. You should always provide the commit title in parentheses so that readers will have some idea what the commit does. > I am using a remote control receiver connected via USB. The remote > control receiver supports wake-on-usb. When I use the remote control > receiver to S3 suspend and resume, it fails to suspend every other time > (i.e, is succeeds on attempts 1,3,5,... and fails on attempts 2,4,6...). > I traced the problem to the first HCD_WAKEUP_PENDING test in the > aforementioned commit. This might be caused by some sort of race (a wakeup request occurring after the WAKEUP_PENDING flag has already been cleared), but I don't see how that would result in the alternating behavior you observe. > Knowing almost nothing about the Linux USB stack, I could not figure out > what was causing the problem. However, by adding > > if (hcd->state == HC_STATE_RUNNING) > clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); > > after > > usb_remote_wakeup(udev); > > in the function drivers/usb/core/hcd.c:hcd_resume_work, I was able to > resolve the problem for my situation. I added the check to > hcd_resume_work because it appears that no matter whatever path the USB > hub resume follows, it always calls hcd_resume_work. However, I have no > idea (1) whether or not this assumption is correct, and (2) whether or > not this is the correct fix. > > I have attached a patch against the 2.6.37 kernel. I don't like to accept patches without understanding the real cause of the problem. 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. 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 @@ -1970,6 +1970,7 @@ int hcd_bus_resume(struct usb_device *rh ? USB_STATE_CONFIGURED : USB_STATE_ADDRESS); hcd->state = HC_STATE_RUNNING; + dev_dbg(&rhdev->dev, "bus resume complete\n"); } else { hcd->state = old_state; dev_dbg(&rhdev->dev, "bus %s fail, err %d\n", @@ -2011,6 +2012,7 @@ void usb_hcd_resume_root_hub (struct usb spin_lock_irqsave (&hcd_root_hub_lock, flags); if (hcd->rh_registered) { set_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); + dev_dbg(&hcd->self.root_hub->dev, "bus resume requested\n"); queue_work(pm_wq, &hcd->wakeup_work); } spin_unlock_irqrestore (&hcd_root_hub_lock, flags); -- 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
