Re: problem with suspending linux-2.6.12-rc1

Re: problem with suspending linux-2.6.12-rc1

[Pavel Machek]

On Po 28-03-05 10:03:06, Ulrich Lauther wrote:
> > Hi!
> > 
> > > since upgrading from 2.6.11 to 2.6.12-rc1 software suspend doesn't work 
> > > anymore for me:
> > > The last I see when suspending (echo 4 > /proc/acpi/sleep) is a
> > > message refering to eth0, then when "writing to swap space" should appear,
> > > the system stops.
> > > 
> > > Please let me know if you need more information.
> > 
> > Standard debugging: try again with init=/bin/bash and minimal set of
> > drivers, and get me last few messages...
> > 
> > 								Pavel
> with init=/bin/bash it works.
> 
> Further experimentation showed that the problem occurs only when X11 is
> running. I then tried to work without the evdev driver (and without the
> alps module in X11, that needs evdev), but that didn't make a
> difference).

Do you have 3D acceleration enabled in X? Does it work if you have X
running but on the background console? Does it work if you quit X then
suspend from console?
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: problem with suspending linux-2.6.12-rc1

[Andy Isaacson]

On Tue, Mar 29, 2005 at 12:20:49AM +0200, Pavel Machek wrote:
> On Po 28-03-05 10:03:06, Ulrich Lauther wrote:
> > > > since upgrading from 2.6.11 to 2.6.12-rc1 software suspend doesn't work 
> > > > anymore for me:
> > > > The last I see when suspending (echo 4 > /proc/acpi/sleep) is a
> > > > message refering to eth0, then when "writing to swap space"
> > > > should appear, the system stops.

This sounds similar to the swsusp hang I started seeing when I upgraded
from 2.6.11 to 2.6.12-rc1; my touchpad was failing to reinitialize, so
input was calling hotplug which tried to exec /sbin/hotplug, and the
exec() blocked because userland was stopped.  If you do Sysrq-T and see
a process with a stack trace like
	wait_for_completion
	call_usermodehelper
	kobject_hotplug
	kobject_del
	class_device_del
	class_device_unregister
	mousedev_disconnect
	input_unregister_device
then you're seeing the same kind of bug.

Try the patch below from Dmitry.

-andy

===================================================================

Input: serio - do not attempt to immediately disconnect port if
       resume failed, let kseriod take care of it. Otherwise we
       may attempt to unregister associated input devices which
       will generate hotplug events which are not handled well
       during swsusp.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>


 serio.c |    1 -
 1 files changed, 1 deletion(-)

Index: dtor/drivers/input/serio/serio.c
===================================================================
--- dtor.orig/drivers/input/serio/serio.c
+++ dtor/drivers/input/serio/serio.c
@@ -779,7 +779,6 @@ static int serio_resume(struct device *d
 	struct serio *serio = to_serio_port(dev);
 
 	if (!serio->drv || !serio->drv->reconnect || serio->drv->reconnect(serio)) {
-		serio_disconnect_port(serio);
 		/*
 		 * Driver re-probing can take a while, so better let kseriod
 		 * deal with it.