2005-03-28 22:21:10

by Pavel Machek

[permalink] [raw]
Subject: Re: problem with suspending linux-2.6.12-rc1

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!


2005-03-31 06:20:05

by Andy Isaacson

[permalink] [raw]
Subject: Re: problem with suspending linux-2.6.12-rc1

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 <[email protected]>


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.