On Mon, 31 Mar 2014, Peter Münster wrote:
> > One more thing... The bad commit should have no effect on devices
> > enabled for wakeup -- and keyboards generally _are_ enabled for wakeup.
> > Can you check this? Under 3.12.x with no patches or reversions,
>
> I've just added your diagnostic patch.
That's okay.
> > plug the mouse into a front port and the keyboard into its usual rear
> > port. Before going into suspend, make sure that the keyboard's
> > power/wakeup file (/sys/bus/usb/devices/4-3/power/wakeup) contains
> > "enabled".
>
> Yes, it was already enabled.
>
>
> > Then test if the suspend and resume work okay -- capture the log with
> > netconsole and let's see what it says.
>
> The log is in attached file "keyboard-rear.log".
> The resume hangs the system as usual.
That's totally crazy. With wakeup enabled, the commit should have had
no effect at all.
Here's another diagnostic patch to try (use it along with the first
one). Do the same test, i.e., only the keyboard in a rear port. This
patch effectively reverts commit 0aa2832dd0d9d860 and instead, prints
out information showing what the commit would do.
(By the way, the first diagnostic patch did provide interesting
information. Maybe you noticed: The frame values were _not_ changing!)
Alan Stern
Index: usb-3.12/drivers/usb/core/hub.c
===================================================================
--- usb-3.12.orig/drivers/usb/core/hub.c
+++ usb-3.12/drivers/usb/core/hub.c
@@ -3021,10 +3021,13 @@ int usb_port_suspend(struct usb_device *
* Therefore we will turn on the suspend feature if udev or any of its
* descendants is enabled for remote wakeup.
*/
- else if (PMSG_IS_AUTO(msg) || wakeup_enabled_descendants(udev) > 0)
+ else if (1) {
+ dev_info(&udev->dev, "port suspend AUTO %d wakeup %d\n",
+ PMSG_IS_AUTO(msg),
+ wakeup_enabled_descendants(udev));
status = set_port_feature(hub->hdev, port1,
USB_PORT_FEAT_SUSPEND);
- else {
+ } else {
really_suspend = false;
status = 0;
}
--
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
