suspend button disappears after pm-utils upgraded to 1.1.2.4-1ubuntu2

I can confirm on Samsung X30. After downgrading the "Suspend" option becomes available again.

This bug is happening because Ubuntu stopped using s2ram, and removed the check for s2ram in the backend autodetection module but not in the actual uswsusp backend. Since the uswsusp backend relies on s2ram to suspend, pm-utils claims that the system does not support suspend.

The easiest way to fix this bug would be to just use the kernel backend and ignore uswsusp.

The second easiest way to fix this bug would be to write a new backend that uses the kernel suspend/resume functionality but continues to use s2disk for hibernation.

pm-utils 1.2.1 or thereabouts will have finegrained suspend method autodetection built-in (http://cgit.freedesktop.org/pm-utils/?h=auto-backend for the branch that will be merged into the 1.2 series of pm-utils)

A short-term workaround would be to add a file (the name does not matter) in /etc/pm/config.d with the following line:

SLEEP_MODULE=kernel

This will tell pm-utils to use the kernel's basic functionality for suspend and hibernate.

SLEEP_MODULE=kernel

After adding this line, suspend button appears, but it doesn't work. System halted after pressing it.

Interesting. Can you attach /var/log/pm-suspend.log to this bug report, along with the output of lshal |grep quirk?

$ cat /var/log/pm-suspend.log
Initial commandline parameters:
Mon Sep 8 12:48:21 CST 2008: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/00clear suspend: disabled.
/usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
/usr/lib/pm-utils/sleep.d/50modules suspend: not applicable.
/usr/lib/pm-utils/sleep.d/90clock suspend: success.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
/usr/lib/pm-utils/sleep.d/95anacron suspend: success.
/usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/96laptop-mode suspend: success.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
/usr/lib/pm-utils/sleep.d/99video suspend: disabled.
Mon Sep 8 12:48:22 CST 2008: performing suspend

$ lshal |grep quirk
  power_management.quirk.vbe_post = true (bool)
  power_management.quirk.vbemode_restore = true (bool)

On Tue, 2008-09-09 at 00:01 +0000, czk wrote:
> $ cat /var/log/pm-suspend.log
> Initial commandline parameters:
> Mon Sep 8 12:48:21 CST 2008: Running hooks for suspend.
> /usr/lib/pm-utils/sleep.d/00clear suspend: disabled.
> /usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
> /usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/50modules suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/90clock suspend: success.
> /usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
> /usr/lib/pm-utils/sleep.d/95anacron suspend: success.
> /usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/96laptop-mode suspend: success.
> /usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
> /usr/lib/pm-utils/sleep.d/99video suspend: disabled.
> Mon Sep 8 12:48:22 CST 2008: performing suspend

Interesting -- when running with the kernel suspend backend, 00clear and
99video should not be disabled -- only the uswsusp module does that.
Looks like that last patch broke pm-utils in a particularly spectacular
fashion.

>
> $ lshal |grep quirk
> power_management.quirk.vbe_post = true (bool)
> power_management.quirk.vbemode_restore = true (bool)

Can you try running pm-suspend manually by running the following command
as root and attaching the resultant /var/log/pm-suspend.log to this bug?

PM_DEBUG=true /usr/sbin/pm-suspend --quirk-vbe-post --quirk-vbemode-restore

This will spew out tons of debugging information into the logfile and
help pinpoint exactly where pm-utils is failing.

--
Victor Lowther
Ubuntu Certified Professional

Sorry, I didn't enabled kernel backend just now. Now it works! Thanks.

The problem appears when uswsusp is installed because of an incorrect test for the use of uswsusp for suspend for SLEEP_MODE=auto.

This is what ships in /usr/lib/pm-utils/pm-functions

        # Try userspace software suspend
        if [ -c /dev/snapshot ] && command_exists s2disk ; then
                SLEEP_MODULE="uswsusp"
        fi

This is what should ship

        # Try userspace software suspend
        if [ -c /dev/snapshot ] && command_exists s2ram ; then
                SLEEP_MODULE="uswsusp"
        fi

The following patch to 10-sleep-mdule-auto-detection.patch appears to resolve the problem

--- pm-utils-1.1.2.4/debian/patches/10-sleep-module-auto-detection.patch.orig 2008-09-18 13:58:46.000000000 -0400
+++ pm-utils-1.1.2.4/debian/patches/10-sleep-module-auto-detection.patch 2008-09-18 11:43:16.000000000 -0400
@@ -20,7 +20,7 @@
 + SLEEP_MODULE="kernel"
 +
 + # Try userspace software suspend
-+ if [ -c /dev/snapshot ] && command_exists s2disk ; then
++ if [ -c /dev/snapshot ] && command_exists s2ram ; then
 + SLEEP_MODULE="uswsusp"
 + fi
 +

However... My thinkpad T61 appears to now get upset with kernel suspend.
So I built debian sid's uswsup-0.8-1 which provides s2ram. And everything appears to be happy now.

Now off to find out why we're still on a 15 month old version of uswsusp, and why splashy.h has gboolean instead of int.

Note that if we check for s2ram when deciding whether to use the uswsusp backend, it will never be used on Ubuntu; that kinda defeats the purpose of having the package, I think.

Hi Steve,

Since the last upload of pm-utils it no longer checks for s2ram when deciding whether to
use uswsusp, only s2disk (and /dev/snapshot). This means that for those with uswsusp installed
it is now used as the backend since this upload. When the uswsusp backend is then asked if
it supports suspend it checks for the presence s2ram, and doesn't find it, and so reports
that suspend is not possible, leading to the issue we are seeing.

Thanks,

James

Looking at this more closely, yes my suggested patch disables
pm-utils use of uswsusp on ubuntu, unless someone installed
the debian uswsusp package.

However, the current behavior is to disable the use of suspend when
ubuntu uswsusp is installed.

The root of this problem appears to be duplication of the check_suspend
and check_hibernate functions between modules.d/*, pm-is-supported, and
pm-utils when our SLEEP_MODULE does not have to be the same
as our hibernate module.

My thoughts without code are.
1) the functions for each module should be uniquely named based on the
module.
module.d/uswsusp's check_suspend should be uswsusp_check_suspend
2) pm-utils should source all files in modules.d/*
3) pm-utils should have something like a checkit() and doit() functions
something like
checkit() {
    local rc=1
    for module in $modules; do
        ${module}_check_$1
        rc=$?
        [ "$rc" == 0 ] && break
    done
    return $rc
}
doit() {
    checkit $1; rc=$?
    [ "$rc" == 0 ] && ${module}_check_$1
}

But that needs to be floated upstream....

--
Chris Dukes
"In cynicism she's about 35" -- Terry Pratchett's "Hog Father"

Hi,

After a mailing list discussion about this bug I propose the attached
patch for inclusion.

Thanks,

James

https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026586.html

https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026589.html

and not in the archives yet from Matthew Garret

"Just drop the Debian-specific patch that uses the uswsusp code at all.
It's an entirely unnecessary deviation from upstream that results in
increased awkwardness.

s2ram was dropped because people in the forums were encouraging people
to install and use it, rather than reporting bugs about the Ubuntu code.
It duplicates the functionality of pmutils and its presence causes user
confusion."

I'm personally against dropping the patch, for the following reasons:
1. This won't stop people who want to use uswsusp from using uswsusp.
2. If the user has installed uswsusp, then, since it's in universe, it should mean that the user has explicitly chosen to use it
3. Dropping the patch would make people who need/want to use uswsusp to rebuild pm-utils with the patch

Matthew Garret disabled the s2ram build because many people decided to use uswsusp instead of reporting bugs in Ubuntu's default suspend code. This means that the rest of us who DO want to use s2ram cannot use it without rebuilding uswsusp. I don't like to put things too harshly, but my personal opinion about this is: this was a very stupid move, stepping around the matter rather than fixing it. If uswsusp broke stuff for some people, then ask them to remove it. Don't start messing up packages just because you feel like fixing stuff for people who wrongly installed a package that wasn't meant for them to begin with. I sincerely hope this doesn't carry to disabling s2disk as well, or just removing the entire uswsusp package altogether.

The way I see it, there are two (acceptable) ways to go about fixing this whole matter:
1. Re-enable s2ram. If people complain things break, tell them to remove s2ram, and mark their bugs invalid.
2. Hack pm-utils code into not looking at s2ram.
In both cases, I would recommend that uswsusp be dropped from Recommends to Suggests in pm-utils.

Method #1 would reverse Matthew Garret's change, and, I believe is the right way to go about things. If we keep stepping around this matter, we'll eventually encounter a greater problem than this. In fact, this whole bug came from disabling s2ram in the first place.

Method #2 would bring things back to how they were before ubuntu2. I wouldn't say it would bring things to how they were back in Hardy, because in Hardy, pm-utils looked for s2disk and s2ram in the wrong places (/usr/sbin instead of /sbin), and so uswsusp didn't work in Hardy anyway.

On Fri, 2008-09-26 at 14:18 +0000, hyperair wrote:
> I'm personally against dropping the patch, for the following reasons:
> 1. This won't stop people who want to use uswsusp from using uswsusp.

That's intentional, if people want to use uswsusp they can.

> 2. If the user has installed uswsusp, then, since it's in universe, it should mean that the user has explicitly chosen to use it

That's not true. I have it installed and I didn't choose to. pm-utils'
presence in the default install and the moving of uswsusp to Suggests
should prevent this happening though.

> 3. Dropping the patch would make people who need/want to use uswsusp to rebuild pm-utils with the patch

I believe this is incorrect, adding a file to /etc/pm/config.d/ will
allow them to use it.

Thanks,

James

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Westby wrote:
> On Fri, 2008-09-26 at 14:18 +0000, hyperair wrote:
>> I'm personally against dropping the patch, for the following reasons:
>> 1. This won't stop people who want to use uswsusp from using uswsusp.
>
> That's intentional, if people want to use uswsusp they can.
>
Then don't disable s2ram.
>> 2. If the user has installed uswsusp, then, since it's in universe, it
> should mean that the user has explicitly chosen to use it
>
> That's not true. I have it installed and I didn't choose to. pm-utils'
> presence in the default install and the moving of uswsusp to Suggests
> should prevent this happening though.
>
Yes, that's the reason why I agree with shifting it to Suggests.
>> 3. Dropping the patch would make people who need/want to use uswsusp
> to rebuild pm-utils with the patch
>
> I believe this is incorrect, adding a file to /etc/pm/config.d/ will
> allow them to use it.
What file would this be? Also, it's a rather hackish method of getting something to work,
considering most of Ubuntu's stuff is configured and enabled upon installation. This deviates from
normal behaviour.
>
> Thanks,
>
> James
>

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI3PpS4LFcUo8CpBERAvL/AJ482fxZlo/PgXSrXeMuzWFFn0irGgCdGpcY
wU/u3xEcuZb8E8yOJu8XKj4=
=Dbew
-----END PGP SIGNATURE-----

On Fri, Sep 26, 2008 at 02:52:34PM -0000, James Westby wrote:
>
> I believe this is incorrect, adding a file to /etc/pm/config.d/ will
> allow them to use it.

Which could be supplied by uswsusp. Which could then be managed
through debconf for uswsusp.
And then there would be grounds to have a uswsusp-s2ram package
that should probably nag and complain that the user really should open
a bug against pm-utils if they must use the package.

--
Chris Dukes
"In cynicism she's about 35" -- Terry Pratchett's "Hog Father"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pakraticus wrote:
> On Fri, Sep 26, 2008 at 02:52:34PM -0000, James Westby wrote:
>> I believe this is incorrect, adding a file to /etc/pm/config.d/ will
>> allow them to use it.
>
> Which could be supplied by uswsusp. Which could then be managed
> through debconf for uswsusp.
> And then there would be grounds to have a uswsusp-s2ram package
> that should probably nag and complain that the user really should open
> a bug against pm-utils if they must use the package.
>
That would be a bad idea. If we want uswsusp to work with pm-utils by default (if uswsusp is
installed) then no changes need to be done. But what James Westby and the rest of them want to do is
allow uswsusp to be installed, and pm-utils doesn't use it unless you explicitly install AND enable
it. Well this effect could be achieved better through the use of debconf, but honestly, too many
prompts by debconf isn't pretty, and should be kept to a minimum.

And also, I agree that if we don't have s2ram even built in the uswsusp package, then we should at
least have a separate package with just s2ram in it.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI3SXM4LFcUo8CpBERAq16AJ43lYsGF1waxMC9d9e9lm+A7QACTwCfSkQF
ifKMGBWXbAy4tSeLE1gSyT8=
=dcix
-----END PGP SIGNATURE-----

Hi,

Attached is an updated patch that deletes the patch as well
as not applying it, as requested by Steve.

Thanks,

James

On Fri, Sep 26, 2008 at 06:11:24PM -0000, hyperair wrote:
> That would be a bad idea. If we want uswsusp to work with pm-utils by default (if uswsusp is
> installed) then no changes need to be done. But what James Westby and the rest of them want to do is
> allow uswsusp to be installed, and pm-utils doesn't use it unless you explicitly install AND enable
> it. Well this effect could be achieved better through the use of debconf, but honestly, too many
> prompts by debconf isn't pretty, and should be kept to a minimum.

People use uswsusp either because
1) It's legacy on a box that was upgraded from hardy to intrepid where
uswsusp was installed for whatever reason.
(How I encountered this).
2) They followed feisty or gutsy vintage instructions.
3) Their hardware does not work properly with the kernel sleep and hibernate
modules for pm-utils.

#1 and #2 could probably withstand applying the rolled up newspaper
treatment to the user.

#3 indicates attempting to conceal a defect in the pm-utils package
and MAYBE it's worthwhile to report the defect in pm-utils.

Right now the crux of the pm-utils defect is that it assumes that the
module for hibernate should also be the module for sleep.
On debian this makes sense as uswsusp provides both hibernate and sleep.
This is a side effect of the revision of the pm-utils code to be more
modular.
Upstream should be notified of the problem in logic prior to distributing
a fix for intrepid.
(I apologize for switching between sleep and suspend... I'm trying to
maintain the same inconsistancy as the pm-utils modules).
>
> And also, I agree that if we don't have s2ram even built in the uswsusp package, then we should at
> least have a separate package with just s2ram in it.

Assuming s2ram is the right solution.
At this point in the game, intrepid is alpha. The prescribed configuration
is pm-utils without uswsusp. If pm-utils fails on suspend or hibernate
with uswsusp on your hardware, the ubuntu developers need to know.

If you installed uswsusp to resolve a hibernate problem and uswsusp
did, maybe the fix is to change the logic in pm-utils instead of
bringing back s2ram.

If the logic on pm-utils is improved to separate the configured module
for sleep from module for hibernate, the long term solution might be for
pm-utils to provide suspend and hibernate blacklists, uswsusp to provide
suspend and hibernate blacklists, and tuxonice to provide suspend and
hibernate blacklists and for pm-is-supported to provide a --verbose
or --recommends flag that indicates which module is being used for
suspend, hibernate, or suspend-hybrid, whether it was hard set
or determined from absence from blacklists, and if it's blacklisted
the next priority package.

--
Chris Dukes
"In cynicism she's about 35" -- Terry Pratchett's "Hog Father"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pakraticus wrote:
> People use uswsusp either because
> 1) It's legacy on a box that was upgraded from hardy to intrepid where
> uswsusp was installed for whatever reason.
> (How I encountered this).
> 2) They followed feisty or gutsy vintage instructions.
> 3) Their hardware does not work properly with the kernel sleep and hibernate
> modules for pm-utils.
4) hibernate/resume takes a long time using pm-utils, because it doesn't involve compression

> #1 and #2 could probably withstand applying the rolled up newspaper
> treatment to the user.
Regarding #1, actually Hardy doesn't have uswsusp installed by default.

> #3 indicates attempting to conceal a defect in the pm-utils package
> and MAYBE it's worthwhile to report the defect in pm-utils.
Perhaps so, but until pm-utils uses compression for hibernation, it's not going to get fixed.

> Right now the crux of the pm-utils defect is that it assumes that the
> module for hibernate should also be the module for sleep.
> On debian this makes sense as uswsusp provides both hibernate and sleep.
> This is a side effect of the revision of the pm-utils code to be more
> modular.
> Upstream should be notified of the problem in logic prior to distributing
> a fix for intrepid.
> (I apologize for switching between sleep and suspend... I'm trying to
> maintain the same inconsistancy as the pm-utils modules).
I say fix it, test it, and submit the patch upstream at the same time. On Ubuntu this whole issue
comes about from two things, one is the assumption that s2disk comes with s2ram, the other is the
actions of the one who came up with the brilliant idea of disabling s2ram.

>> And also, I agree that if we don't have s2ram even built in the uswsusp package, then we should at
>> least have a separate package with just s2ram in it.
>
> Assuming s2ram is the right solution.
> At this point in the game, intrepid is alpha. The prescribed configuration
> is pm-utils without uswsusp. If pm-utils fails on suspend or hibernate
> with uswsusp on your hardware, the ubuntu developers need to know.
This point does not make the assumption that s2ram is the right solution. This is about giving the
user a choice. Now that uswsusp is only in Suggests and not in Recommends, apt-get autoremove should
get rid of it right? I remember uswsusp wasn't installed in my Hardy installation, so users who
upgrade from Hardy to Intrepid won't have a problem if we make sure the upgrade process doesn't
install pm-utils.

> If you installed uswsusp to resolve a hibernate problem and uswsusp
> did, maybe the fix is to change the logic in pm-utils instead of
> bringing back s2ram.
> If the logic on pm-utils is improved to separate the configured module
> for sleep from module for hibernate, the long term solution might be for
> pm-utils to provide suspend and hibernate blacklists, uswsusp to provide
> suspend and hibernate blacklists, and tuxonice to provide suspend and
> hibernate blacklists and for pm-is-supported to provide a --verbose
> or --recommends flag that indicates which module is being used for
> suspend, hibernate, or suspend-hybrid, whether it was hard set
> or determined f...

On Friday 26 September 2008 20:54:23 pakraticus wrote:
> 3) Their hardware does not work properly with the kernel sleep and hibernate modules for pm-utils.

I used to use pm-hibernate a lot but it stop working sometime after kernel 2.6.27.
FUSA option do nothing for me either.
Maybe I need to reinstall my system with Beta and test

--
BUGabundo :o)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

On Saturday 27 September 2008 07:23:31 hyperair wrote:
> 4) hibernate/resume takes a long time using pm-utils, because it doesn't involve compression

Mine takes almost as long as a regular boot.
Is it any faster for anybody else?? I would love it...

How can I make my suspend/hibernate work again?

--
BUGabundo :o)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BUGabundo wrote:
> On Saturday 27 September 2008 07:23:31 hyperair wrote:
>> 4) hibernate/resume takes a long time using pm-utils, because it doesn't involve compression
>
> Mine takes almost as long as a regular boot.
> Is it any faster for anybody else?? I would love it...
>
> How can I make my suspend/hibernate work again?
>
It's faster with s2disk. Install uswsusp and check the timing (run sudo s2disk from terminal). The
problem here is that our dear Ubuntu devs don't like uswsusp, and insist on leaving us Ubuntu users
in the pits of slow hibernate/resume hell.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI3fmN4LFcUo8CpBERAsxwAKCoUYkW4mYV1KxvMw5p+YfHVoYbpACeNFqw
7fjqQUxTj2bheEBN1KuJwsQ=
=8/z4
-----END PGP SIGNATURE-----

$ sudo s2disk
s2disk: Could not stat the resume device file. Reason: No such file or directory

$ ls /dev/disk/by-uuid/ -lah
total 0
drwxr-xr-x 2 root root 120 2008-09-27 08:55 ./
drwxr-xr-x 6 root root 120 2008-09-27 08:55 ../
lrwxrwxrwx 1 root root 10 2008-09-27 08:48 468553ea-c737-4d2a-859c-9b0720c89d1a -> ../../sda2
lrwxrwxrwx 1 root root 10 2008-09-27 08:55 48D1-83BF -> ../../sdb1
lrwxrwxrwx 1 root root 10 2008-09-27 08:48 763f105e-4a47-4484-8ff5-3b1987ed5813 -> ../../sda5
lrwxrwxrwx 1 root root 10 2008-09-27 08:48 a8aa4adb-b3e6-4e1d-b4ad-e6cd704788b2 -> ../../sda1

$ cat /etc/uswsusp.conf
# /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both
resume device = UUID=468553ea-c737-4d2a-859c-9b0720c89d1a
splash = y
compress = y
early writeout = y
image size = 1908239564
RSA key file = /etc/uswsusp.key

that UUID is swap
$ sudo fdisk -l
Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000acc4b

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 1216 9767488+ 83 Linux
/dev/sda2 1217 2189 7815622+ 82 Linux swap / Solaris
/dev/sda3 2190 38913 294985530 5 Extended
/dev/sda5 2190 38913 294985498+ 83 Linux

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BUGabundo wrote:
> resume device = UUID=468553ea-c737-4d2a-859c-9b0720c89d1a
This really isn't the right place for some sort of support discussion, but just replace the UUID
with /dev/sda2 and see if it works. Mine's set to a path, not a UUID. If you still want the UUID
perhaps /dev/disk/by-uuid/468553ea-c737-4d2a-859c-9b0720c89d1a ?
- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI3gia4LFcUo8CpBERAsOyAJ9aTMuI4GmceC8f6sS7QDuqQOc8OQCfX7qb
TztlUjwM4zn/UWBtCSioBgI=
=izVE
-----END PGP SIGNATURE-----

"dpkg --purge uswsusp" fixes the problem for me. After doing that and rebooting (update-initramfs is run), I have suspend back in the Gnome power manager and suspend works too.

I've worked on it a little, and managed to patch pm-utils to use
kernel's do_suspend and check_suspend, as well as uswsusp for the rest
(when auto-detected). The patch also makes sure that uswsusp's
before_hooks only executes the commands in it when hibernating, and not
when suspending.

--
Chow Loong Jin

Hi,

Thanks for working on this. Your patch looks sensible to me, however there
was a new upstream release over the weekend, including this:

      * Sleep modules are stackable and have finegrained method
        detection. For instance, if you like s2disk but not s2ram, you
        can remove the s2ram binary and pm-utils will automatically fall
        back to using kernel methods for suspend/resume.

so we should perphaps evaluate using the new upstream version, or
backporting this fix to our current package.

I plan to look at this soon.

Thanks,

James

If you want to look at pulling the upstream package, start with 1.2.2.1 -- the previous 1.2.1 and 1.2.2 releases are buggy.

On Mon, 2008-10-06 at 11:58 +0000, vlowther wrote:
> If you want to look at pulling the upstream package, start with 1.2.2.1
> -- the previous 1.2.1 and 1.2.2 releases are buggy.
>

Ah, I'd missed 1.2.2.1, thanks for the heads-up.

I'm not sure whether going for this is the right idea, as opposed
to back-porting the change quoted above, because I'm not sure
the impact the auto-quirk change will have.

Do you have any opinion on this? It's very late in the cycle
to pull in something that could be potentially disruptive.

Thanks,

James

On Mon, 2008-10-06 at 12:16 +0000, James Westby wrote:
> On Mon, 2008-10-06 at 11:58 +0000, vlowther wrote:
> > If you want to look at pulling the upstream package, start with 1.2.2.1
> > -- the previous 1.2.1 and 1.2.2 releases are buggy.
> >
>
> Ah, I'd missed 1.2.2.1, thanks for the heads-up.
>
> I'm not sure whether going for this is the right idea, as opposed
> to back-porting the change quoted above, because I'm not sure
> the impact the auto-quirk change will have.
>
> Do you have any opinion on this? It's very late in the cycle
> to pull in something that could be potentially disruptive.
>
> Thanks,
>
> James
>
I'll agree with you on that. But whatever it is, I'm against leaving it
broken the way it is at the moment. Is there anybody in charge of
pm-utils that we can subscribe to this bug? I don't think it's getting
enough attention from the appropriate people, or at least, if they know
or are subscribed, they don't seem to be paying much attention.
--
Chow Loong Jin

On Mon, 2008-10-06 at 13:05 +0000, hyperair wrote:
> I'll agree with you on that. But whatever it is, I'm against leaving it
> broken the way it is at the moment.

I agree, and it's not going to stay broken. I was asking Victor what
his opinion was; as he is the upstream author he knows the package
better than anyone.

Thanks,

James

On Thu, Oct 2, 2008 at 10:50 AM, Michael Milligan <email address hidden> wrote:
> "dpkg --purge uswsusp" fixes the problem for me. After doing that and
> rebooting (update-initramfs is run), I have suspend back in the Gnome
> power manager and suspend works too.

That fixes it for me too.

--
Martin <http://launchpad.net/~mbp/>

On Mon, 2008-10-06 at 12:16 +0000, James Westby wrote:
> On Mon, 2008-10-06 at 11:58 +0000, vlowther wrote:
> > If you want to look at pulling the upstream package, start with 1.2.2.1
> > -- the previous 1.2.1 and 1.2.2 releases are buggy.
> >
>
> Ah, I'd missed 1.2.2.1, thanks for the heads-up.

I didn't exactly go out of my way to announce it, more sort of mentinoed
it in passing on a thread on the pm-utils mailing list. The actual
announcement will come later tonight.

> I'm not sure whether going for this is the right idea, as opposed
> to back-porting the change quoted above, because I'm not sure
> the impact the auto-quirk change will have.

Well, the whole 1.1 -> 1.2 transition is fairly large, and most of the
current debian patches will need to be rewritten or junked to work with
it. I have been running it on my laptop since I started coding it, but
I don't have much of an idea about who else has been -- feedback on the
pm-utils list is sparse. My real feedback and testing mostly comes from
debian sid, but the latest revisions have not been picked up by sid yet.

The auto-quirk changes are actually not that invasive -- they will not
affect anything when pm-utils is invoked bu HAL, for example, and all
the actual auto-quirk code is contained in the 00auto-quirk hook.

The auto backend stuff is much more invasive, but it was written to make
these sorts of issues harder to create.

The much more invasive thing is the hook reordering, but that will make
suspend/resume seem to be much faster due to most of the time consuming
parts of resume happening after we switch back to X or the active
console.

> Do you have any opinion on this? It's very late in the cycle
> to pull in something that could be potentially disruptive.

Well, it Works For Me (tm).

If people are willing to test things out, 1.2.2.1 will be in debian
experimental shortly, and the .deb itself should install seamlessly into
Ubuntu.

> Thanks,
>
> James
>
--
Victor Lowther
Ubuntu Certified Professional

Okay, since pm-utils got upgraded to ubuntu4, I've created a new debdiff
for the time being, which I've attached. Would it be a good idea to at
least get this uploaded now, and then continue considering whether or
not we should upgrade to 1.2.2.1?
--
Chow Loong Jin

I feel like this is already intrinsically disruptive for any Ubuntu users who try to use it - I'd like to see, at minimum, the above patch go in. Ideally, I'd like to see 1.2.2.1 - this was certainly disruptive for me, as a user, when I upgraded and found my suspend button missing; since hibernate doesn't work on my laptop, this left me SOL.

I can't suspend on Lenovo Thinkpad X200 with Intel GMA X4500. Have this problem been fixed yet? Or will it be fixed for final release?

Thank you so much Milligan.
That fix my problem, and now I have suspend and hibernation again.
Suspend is a bit slower than it used to.

So, any tips on how to do compress images, so hibernation takes just a few secs, instead of 45 sec?

I'm sorry to say that I don't think upgrading pm-utils to the new upstream version is a viable option for intrepid. Backporting a targeted fix may be, if someone wants to look into the code differences; but I think we should consider other fixes in the meantime, even if they end up being short-term.

Of the two patches available, I'm afraid I'm not happy at all with hyperair's, which adds nearly 100% code duplication of the existing uswsusp method; that's not at all elegant or maintainable.

James' patch, while making it more awkward to enable uswsusp, does address the core of this bug, which is that users should not lose the suspend method by having uswsusp installed. Being able to use uswsusp, which is a far-from-preferred method in Ubuntu, is very much secondary.

So I think James' patch is the correct basis on which to move this bug forward. James, it's been mentioned that dropping a file in /etc/pm/config.d with the sleep method is enough to let users enable uswusp. Perhaps we should patch pm-utils to ship a file under /etc/pm/config.d by default, with commented examples of how to enable the alternate suspend methods? I don't believe that installation of the uswsusp package (or tuxonice support in the kernel) should cause these methods to be used automatically, given their non-preferred status within Ubuntu, so an example file seems best to me.

On Wed, 2008-10-08 at 07:46 +0000, Steve Langasek wrote:
> I'm sorry to say that I don't think upgrading pm-utils to the new
> upstream version is a viable option for intrepid. Backporting a
> targeted fix may be, if someone wants to look into the code differences;
> but I think we should consider other fixes in the meantime, even if they
> end up being short-term.
>
> Of the two patches available, I'm afraid I'm not happy at all with
> hyperair's, which adds nearly 100% code duplication of the existing
> uswsusp method; that's not at all elegant or maintainable.
>
I agree that there is a lot of code duplication. I'll see if I can do
anything about this later today.
> James' patch, while making it more awkward to enable uswsusp, does
> address the core of this bug, which is that users should not lose the
> suspend method by having uswsusp installed. Being able to use uswsusp,
> which is a far-from-preferred method in Ubuntu, is very much secondary.
>
> So I think James' patch is the correct basis on which to move this bug
> forward. James, it's been mentioned that dropping a file in
> /etc/pm/config.d with the sleep method is enough to let users enable
> uswusp. Perhaps we should patch pm-utils to ship a file under
> /etc/pm/config.d by default, with commented examples of how to enable
> the alternate suspend methods? I don't believe that installation of the
> uswsusp package (or tuxonice support in the kernel) should cause these
> methods to be used automatically, given their non-preferred status
> within Ubuntu, so an example file seems best to me.
>
Actually, something I realized while I was making my patch is that
uswsusp is that dropping a file in /etc/pm/config.d, presumably
containing 'SLEEP_MODULE="uswsusp"' will make this bug resurface, since
this setting will cause uswsusp to be used for check_suspend and
do_suspend as well, unless of course, the build of s2ram is re-enabled
in uswsusp. Hence it's not just "more awkward" to enable uswsusp, it
involves a few setbacks that can only be fixed by making the same
invasive changes (unless there's a better approach) as the patch I've
made.
--
Chow Loong Jin

Here it is. No more code duplication.

--
Chow Loong Jin

so how do I apply these debdiffs?

do I need to uninstall uswswap?

adding the kernel option in /etc/pm/config.d/ doesn't work

what I'm trying to ask is, a small step by step for someone who has lost track due to all the jargon like: s2ram, uswswap, kernel suspend. But does want a suspending machine :)

On Wed, 2008-10-08 at 18:25 +0000, dlgandalf wrote:
> so how do I apply these debdiffs?
>
> do I need to uninstall uswswap?
>
> adding the kernel option in /etc/pm/config.d/ doesn't work
>
> what I'm trying to ask is, a small step by step for someone who has lost
> track due to all the jargon like: s2ram, uswswap, kernel suspend. But
> does want a suspending machine :)
debdiffs are for those who know how to use them, or for reviewing by
those who are going to fix the bug. If you're just looking for a quick
fix on your machine, then removing uswsusp will do the trick.
--
Chow Loong Jin

Hi,

Attached is the updated patch to add the example file in /etc/pm/config.d/

Thanks for working on the alternative patch, it has helped me to
understand the issues better. I have just posted a message on
the ubuntu-devel mailing list asking for opinions on re-enabling s2ram
if my patch is applied here, as users will have to make an explicit
choice to use it. How would you feel about that solution? Note that
it's not guaranteed to happen for Intrepid.

Thanks,

James

The config file you dropped in /etc/pm/config.d looks a tad bit like a
block of code taken out of /usr/lib/pm-utils/defaults. Doesn't that seem
a little redundant? I mean, that particular functionality can be gotten
by just modifying the SLEEP_MODULE in the file I mentioned above.
--
Chow Loong Jin

On Fri, 2008-10-10 at 01:51 +0000, hyperair wrote:
> The config file you dropped in /etc/pm/config.d looks a tad bit like a
> block of code taken out of /usr/lib/pm-utils/defaults. Doesn't that seem
> a little redundant? I mean, that particular functionality can be gotten
> by just modifying the SLEEP_MODULE in the file I mentioned above.

Hi,

Yes, that's where it is taken from.

You can't edit /usr/lib/pm-utils/defaults, as your changes would just be
overwritten on upgrades.

Thanks,

James

On Fri, 2008-10-10 at 09:20 +0000, James Westby wrote:
> On Fri, 2008-10-10 at 01:51 +0000, hyperair wrote:
> > The config file you dropped in /etc/pm/config.d looks a tad bit like a
> > block of code taken out of /usr/lib/pm-utils/defaults. Doesn't that seem
> > a little redundant? I mean, that particular functionality can be gotten
> > by just modifying the SLEEP_MODULE in the file I mentioned above.
>
> Hi,
>
> Yes, that's where it is taken from.
>
> You can't edit /usr/lib/pm-utils/defaults, as your changes would just be
> overwritten on upgrades.
>
> Thanks,
>
> James
>
Ah yes, that's a good point. Then wouldn't it be a good idea to remove
the block from /usr/lib/pm-utils/defaults? Having it in two places is
redundant and can cause confusion.
--
Chow Loong Jin

On Fri, 2008-10-10 at 10:15 +0000, hyperair wrote:
> Ah yes, that's a good point. Then wouldn't it be a good idea to remove
> the block from /usr/lib/pm-utils/defaults? Having it in two places is
> redundant and can cause confusion.

Perhaps.

It does say at the top of the file "Do not edit this file, create a file
in /etc/pm/config.d/ instead".

Thanks,

James

note that the dependency currently breaks the ubuntu-mobile image since that is built from universe. getting this dependency revmoved asap would be really appreciated, as we dont get proper feedback about suspend issues on UMPCs and netbooks due to uswsusp being installed by default atm.

I read the thread, and I like James' latest patch (http://launchpadlibrarian.net/18377887/pm-utils_1.1.2.4-1ubuntu6.diff) a lot, too. I'm going to sponsor it now, thanks to all for working on this!

This bug was fixed in the package pm-utils - 1.1.2.4-1ubuntu7

---------------
pm-utils (1.1.2.4-1ubuntu7) intrepid; urgency=low

  * Drop debian/patches/10-sleep-module-auto-detection.patch as we don't
    want to use uswsusp unless the user explicitly chooses it. (LP: #267141)
  * Add an example file /etc/pm/config.d/00sleep_module that shows the user
    how to change the sleep module in use, for instance if they want to
    enable uswsusp.

 -- James Westby <email address hidden> Fri, 26 Sep 2008 12:28:19 +0100

On Wed, 2008-10-15 at 08:09 +0000, Martin Pitt wrote:
> I read the thread, and I like James' latest patch
> (http://launchpadlibrarian.net/18377887/pm-utils_1.1.2.4-1ubuntu6.diff)
> a lot, too. I'm going to sponsor it now, thanks to all for working on
> this!

I've mentioned this before, but I'd like to reiterate that with the
above patch, pm-utils will not be able to use suspend at all when
uswsusp is chosen instead of kernel, using the example which has been
dropped in /etc/pm/config.d. Could something be done about this? Perhaps
re-enable s2ram in uswsusp, since it isn't going to be the default
anyway? Or perhaps mix and match the patches (remove the autodetection
code and default to kernel, but patch pm/module.d/uswsusp to fall back
on kernel for check_suspend and do_suspend)?

--
Chow Loong Jin

Hi,

I am aware of the issue, and I think the others are too.

I would actually lean towards removing uswsusp from the archive,
if we don't want people to use it, and we make it very difficult to
do so, then having it in the archive is just a cause of confusion in
my opinion.

Enabling s2ram would allow it to work, yes, but then we have to
deal with two sources of problems, when it's not immediately
clear which method the user is using, and it doesn't help to get
the kernel method fixed, which should be able to work for everybody.

Thanks,

James

On Wed, 2008-10-15 at 10:26 +0000, James Westby wrote:
> Hi,
>
> I am aware of the issue, and I think the others are too.
>
> I would actually lean towards removing uswsusp from the archive,
> if we don't want people to use it, and we make it very difficult to
> do so, then having it in the archive is just a cause of confusion in
> my opinion.
>
> Enabling s2ram would allow it to work, yes, but then we have to
> deal with two sources of problems, when it's not immediately
> clear which method the user is using, and it doesn't help to get
> the kernel method fixed, which should be able to work for everybody.
>
> Thanks,
>
> James

Basically you're saying keep it broken until the long term fix comes
out?

Whatever happened to "freedom of choice"? By leaving uswsusp broken in
this manner, it forces users who would choose to use uswsusp to just use
the kernel method. And I prefer uswsusp over the kernel method for
hibernating because the kernel method takes an incredibly long time for
resuming from hibernation, which is around the same amount of time taken
for starting up the computer.

Until the kernel method gets up to speed, why not at least allow users
to use uswsusp?

I can already picture this conversation happening somewhere in the
world:
A: Ubuntu takes so long to hibernate and resume! Why?!
B: Because Ubuntu uses the kernel method for hibernating which doesn't
involve compression.
A: Well, can I use another method to make it faster?
B: Yeah, there's uswsusp, but you can't use it because the Ubuntu devs
don't want you to.
A: Why don't they want me to?
B: Ask them.

--
Chow Loong Jin

Olá hyperair e a todos.

On Wednesday 15 October 2008 11:48:55 hyperair wrote:
> A: Ubuntu takes so long to hibernate and resume! Why?!
> B: Because Ubuntu uses the kernel method for hibernating which doesn't
> involve compression.
> A: Well, can I use another method to make it faster?
> B: Yeah, there's uswsusp, but you can't use it because the Ubuntu devs
> don't want you to.

Will this patch make my hibernate/resume faster?
That's all I want to know
--
BUGabundo :o)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

On Wed, 2008-10-15 at 11:26 +0000, BUGabundo wrote:
> Olá hyperair e a todos.
>
> On Wednesday 15 October 2008 11:48:55 hyperair wrote:
> > A: Ubuntu takes so long to hibernate and resume! Why?!
> > B: Because Ubuntu uses the kernel method for hibernating which doesn't
> > involve compression.
> > A: Well, can I use another method to make it faster?
> > B: Yeah, there's uswsusp, but you can't use it because the Ubuntu devs
> > don't want you to.
>
> Will this patch make my hibernate/resume faster?
> That's all I want to know
> --
> BUGabundo :o)
> (``-_-´´) http://LinuxNoDEI.BUGabundo.net
> Linux user #443786 GPG key 1024D/A1784EBB
> My new micro-blog @ http://BUGabundo.net

If uswsusp supports your system and uswsusp is configured properly (last
time you asked me about uswsusp, your /etc/uswsusp.conf wasn't correct),
then yes.

--
Chow Loong Jin

I've reinstalled uswsusp, let it reconfigure with default settings.

$ cat /etc/uswsusp.conf
# /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both
resume device = /dev/sda2
compress = y
early writeout = y
image size = 1910240542
RSA key file = /etc/uswsusp.key
shutdown method = platform

Edited /etc/pm/config.d/00sleep_module :
$ cat /etc/pm/config.d/00sleep_module
# The sleep/wake system to use. Valid values are:
# kernel The built-in kernel suspend/resume support.
# Use this if nothing else is supported on your system.
# uswsusp If your system has support for the userspace
# suspend programs (s2ram/s2disk/s2both), then use this.
# tuxonice If your system has support for tuxonice, use this.
#
# The system defaults to "kernel" if this is commented out.
# SLEEP_MODULE="kernel"
SLEEP_MODULE="uswsusp"

1st tried uswsusp, and my system hibernated as expected with s2disk. It took a while (just about as regular hibernation) but the progress % was nice.
Resume worked too.

Then I tried tuxonice, but it failed to halt the machine. alt+sysreq[+fn]+b rebooted my system, so Kernel was still active.
Resume worked fine, once again.

--
BUGabundo :o)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

I don't know if anybody cares about another vote in favour of uswsusp but after spending a couple of hours trying to make suspend work again after upgrading to Intrepid from Feisty (via Hardy) I was only able to make it work by using uswsusp on HP nw8000 notebook. Removing uswsusp from Ubuntu would make it completely useless on this machine (it's already on a good way after somehow dropping support for its videocard in fglrx which worked without problems for 4 years...).

The ideological purity of kernel-based suspend is all very nice but some of us want to suspend their notebook *now*, not in a couple of years.

If kernel suspend doesn't work on your hardware, please file a separate bug report against the linux package.