Re: problem with resume after s2ram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25 Mar 2014, Peter Münster wrote:

> On Mon, Mar 24 2014, Alan Stern wrote:
> 
> > All three files show the system hanging after the resume, even the file
> > with nothing in the rear ports.  Also, the logs are incomplete; it
> > looks like a bunch of stuff is missing from the start of the suspend.  
> > Did you use netconsole to collect the logs?
> 
> Hi,
> 
> Yes. And just before, I've made "echo 8 >/proc/sys/kernel/printk"

Okay.  I guess netconsole doesn't work very well during system suspend.

> > Oddly, this log is much more complete than the others.  Did you collect 
> > it the same way?
> 
> No. I've used /var/log/messages.

That explains why it is more complete.

> > This is very puzzling.  Let's try one more combination.  Can you
> > collect a log showing 3.14 with commit 0aa2832dd0d9d8 reverted and the 
> > mouse & keyboard both plugged into the rear ports?
> 
> Yes. Please find attached the log (kernel 3.12.14). I attach also the
> hub.c that I use, because there were conflicts, that I've resolved
> manually.

This looks normal.

Clearly we aren't making much progress, mainly because it's so hard to 
get debugging data during system suspend.  So let's try something else 
-- maybe the same problem will arise during runtime suspend.

Below is a patch you should apply to normal 3.14 (nothing reverted).  
It will cause the 0aa2832dd0d9d8 change to take effect during runtime 
suspend as well as system suspend.

For this test, plug some device you aren't going to use (the mouse, for
example, if you will be at a VT console instead of a graphics console) 
into the rear port normally used by the mouse.  Plug the keyboard and 
anything else into front ports -- no other devices should be attached 
to a rear port.

Then you can force the test device to go into runtime suspend by typing 
this:

	echo auto >/sys/bus/usb/devices/4-2/power/control
	echo 0 >/sys/bus/usb/devices/4-2/bConfigurationValue

(I believe 4-2 is the correct path for the rear port where you like to 
plug the mouse.)

After 5 seconds or so, force the device to resume by typing:

	echo on >/sys/bus/usb/devices/4-2/power/control

Let's see what shows up in the kernel log.  With luck the resume will 
hang but the rest of your system will keep on running.

Alan Stern



Index: usb-3.14/drivers/usb/core/hub.c
===================================================================
--- usb-3.14.orig/drivers/usb/core/hub.c
+++ usb-3.14/drivers/usb/core/hub.c
@@ -3015,7 +3015,7 @@ 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 (0)
 		status = set_port_feature(hub->hdev, port1,
 				USB_PORT_FEAT_SUSPEND);
 	else {

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux