Suspend/resume - Request for Testing
Robby Workman
of course), and I'd like to get some more widespread testing with it.
This new release automatically queries the HAL "quirks" database, so in
theory, suspend/resume should work on almost all laptops with it.
Testing is relatively straightforward, but due to its experimental
nature, backups are expected. If you don't have backups and you lose
data, don't blame me or pm-utils.
Package here:
http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2-i486-1_rlw.tgz
Sources here:
http://rlworkman.net/pkgs/sources/12.1/pm-utils/
Once it's installed, running "pm-suspend" as root should do a suspend
to ram, and "pm-hibernate" should suspend to disk. Note that you
must have a swap partition (or file, but partition is easier) which is
large enough (2x ram is good here) and the relevant initrd lines and
such for this to work. If you're not familiar with all of that, don't
test pm-hibernate. [1]
If it works for you, and/or you want to automate it a bit, you'll find
some sample acpi event declarations and scripts here:
http://rlworkman.net/conf/acpi/
The "s2ram.sh" and "s2disk.sh" scripts are currently written to use the
default kernel methods, but they're commented with how to change them
to use pm-utils methods.
[1] Here's the short version of using suspend to disk:
Stanza in /etc/lilo.conf should look something like this:
image = /boot/vmlinuz-generic-smp-2.6.26.5-smp
initrd = /boot/initrd.gz
append = "resume=/dev/hda2"
root = /dev/hda1
label = Slackware
read-only
/etc/mkinitrd.conf should look something like this:
MODULE_LIST="jfs"
ROOTDEV="/dev/hda1"
ROOTFS="jfs"
RESUMEDEV="/dev/hda2"
mkinitrd command invocation would be this:
mkinitrd -c -k 2.6.26.5-smp -F
All of the above assumes at least a cursory understanding of what those
commands and parameters do. If it's not clear, don't attempt it on a
system that you can't easily reinstall without concern.
-RW
Robby Workman
> I've just finished packaging pm-utils 1.2.2 for Slackware (unofficially,
> of course), and I'd like to get some more widespread testing with it.
> This new release automatically queries the HAL "quirks" database, so in
> theory, suspend/resume should work on almost all laptops with it.
For the record, my testing ability on this is quite limited due to the
hardware I have available. All of my laptops are Thinkpads, and the
kernel suspend/resume is pretty much flawless on them; that's why I'm
requesting more widespread testing...
-RW
Grant
>I've just finished packaging pm-utils 1.2.2 for Slackware (unofficially,
>of course), and I'd like to get some more widespread testing with it.
>This new release automatically queries the HAL "quirks" database, so in
>theory, suspend/resume should work on almost all laptops with it.
>
>Testing is relatively straightforward, but due to its experimental
>nature, backups are expected. If you don't have backups and you lose
>data, don't blame me or pm-utils.
>
>Package here:
> http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2-i486-1_rlw.tgz
>Sources here:
> http://rlworkman.net/pkgs/sources/12.1/pm-utils/
>
>Once it's installed, running "pm-suspend" as root should do a suspend
>to ram, and "pm-hibernate" should suspend to disk. Note that you
>must have a swap partition (or file, but partition is easier) which is
>large enough (2x ram is good here) and the relevant initrd lines and
>such for this to work. If you're not familiar with all of that, don't
>test pm-hibernate. [1]
Well, I just did a fresh install of 12.1 and compiled a new kernel for
the laptop and nothing happened:
root@toshi:~# installpkg pm-utils-1.2.2-i486-1_rlw.tgz
Installing package pm-utils-1.2.2-i486-1_rlw...
PACKAGE DESCRIPTION:
pm-utils: pm-utils (Power Management Utilities)
pm-utils:
pm-utils: The pm-utils package provides simple shell command line tools
pm-utils: to suspend and hibernate computers that can be used to run
pm-utils: vendor or distro supplied scripts on suspend and resume.
pm-utils:
pm-utils: Homepage: http://webcvs.freedesktop.org/pm-utils/pm-utils/
pm-utils:
Executing install script for pm-utils-1.2.2-i486-1_rlw...
root@toshi:~# pm-suspend
root@toshi:~# pm-hibernate
root@toshi:~# uname -r
2.6.26.5a
Not even a crash... May try another day, when I have the lappy more
setup.
Was this thing meant to work for slack-12.1 or -current?
>
>If it works for you, and/or you want to automate it a bit, you'll find
>some sample acpi event declarations and scripts here:
> http://rlworkman.net/conf/acpi/
>The "s2ram.sh" and "s2disk.sh" scripts are currently written to use the
>default kernel methods, but they're commented with how to change them
>to use pm-utils methods.
>
>
>[1] Here's the short version of using suspend to disk:
>
> Stanza in /etc/lilo.conf should look something like this:
> image = /boot/vmlinuz-generic-smp-2.6.26.5-smp
> initrd = /boot/initrd.gz
> append = "resume=/dev/hda2"
> root = /dev/hda1
> label = Slackware
> read-only
>
> /etc/mkinitrd.conf should look something like this:
> MODULE_LIST="jfs"
> ROOTDEV="/dev/hda1"
> ROOTFS="jfs"
> RESUMEDEV="/dev/hda2"
>
> mkinitrd command invocation would be this:
> mkinitrd -c -k 2.6.26.5-smp -F
>
> All of the above assumes at least a cursory understanding of what those
> commands and parameters do. If it's not clear, don't attempt it on a
> system that you can't easily reinstall without concern.
I assume it should work wihout an initrd? Lappy wont boot the generic
slack kernel. The huge is okay, except fot loading a botload of irrelevant
drivers -- but you know I favour custom kernels :) And yes, I enabled
s2r + s2d in the kernel as well as nomiate the swap partitioon, but
I've never seen linus go sleepy-byes -- just read the horror stories
about how it doesn't work.
Grant.
--
http://bugsplatter.id.au/
Robby Workman
>
> Well, I just did a fresh install of 12.1 and compiled a new kernel for
> the laptop and nothing happened:
>
> root@toshi:~# pm-hibernate
> root@toshi:~# uname -r
> 2.6.26.5a
>
> Not even a crash... May try another day, when I have the lappy more
> setup.
>
> Was this thing meant to work for slack-12.1 or -current?
Should work on either one.
One of these routines should tell you whether any of the operations
are supported by your current kernel/userspace at all:
for i in hibernate suspend suspend-hybrid ; do
pm-is-supported --$i && echo "$i is supported" || echo "$i is not supported" ;
done
cat /sys/power/state
This is another of those things that, because I'm on a Thinkpad, I may
not be aware of all the system-specific knobs to tweak. Perhaps there's
some special module(s) that need(s) to be loaded.
-RW
enos76
> I've just finished packaging pm-utils 1.2.2 for Slackware (unofficially,
> of course), and I'd like to get some more widespread testing with it.
> [...]
Installs and runs perfectly on my T60 with ATIx1400 with slack 12.1 .
It finally solved the problem with the blank console after suspend to
RAM. Nor the kernel parameter acpi_sleep=s3_bios nor the vbetool utility
helped, but this "pm-suspend --quirks-s3-bios" works great.
Thank you so much.
--
enos76 from Italy
Robby Workman
> Package here:
> http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2-i486-1_rlw.tgz
> Sources here:
> http://rlworkman.net/pkgs/sources/12.1/pm-utils/
Update:
http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2.1-i486-1_rlw.tgz
Sources in same place.
-RW
Grant
...
>> Was this thing meant to work for slack-12.1 or -current?
>
>
>Should work on either one.
>
>One of these routines should tell you whether any of the operations
>are supported by your current kernel/userspace at all:
>
> for i in hibernate suspend suspend-hybrid ; do
> pm-is-supported --$i && echo "$i is supported" || echo "$i is not supported" ;
> done
>
> cat /sys/power/state
root@toshi:~# for i in hibernate suspend suspend-hybrid; \
do pm-is-supported --$i && echo "$i is supported" || \
echo "$i is not supported" ; done
hibernate is supported
suspend is not supported
suspend-hybrid is not supported
root@toshi:~# cat /sys/power/state
standby disk
Okay, so I need to check kernel options and other stuff, config and dmesg
and lappy info are here:
http://bugsplatter.id.au/kernel/boxen/toshi/
>
>This is another of those things that, because I'm on a Thinkpad, I may
>not be aware of all the system-specific knobs to tweak. Perhaps there's
>some special module(s) that need(s) to be loaded.
This is a nine-year-old Toshiba, 500MHz coppermine celeron, 192MB memory.
Grant.
--
http://bugsplatter.id.au/
Grant
Okay,I'm reading and learning more about suspend2disk (hibernate),
and would like to know if you've considered this little gem:
"In principle it does not require ACPI or APM, although for example
ACPI will be used for the final steps when it is available. One
of the reasons to use software suspend is that the firmware hooks
for suspend states like suspend-to-RAM (STR) often don't work very
well with Linux.
It creates an image which is saved in your active swap. Upon the next
boot, pass the 'resume=/dev/swappartition' argument to the kernel to
have it detect the saved image, restore memory state from it, and
continue to run as before. If you do not want the previous state to
be reloaded, then use the 'noresume' kernel command line argument.
Note, however, that fsck will be run on your filesystems and you will
need to run mkswap against the swap partition used for the suspend.
It also works with swap files to a limited extent (for details see
<file:Documentation/power/swsusp-and-swap-files.txt>).
Right now you may boot without resuming and resume later but in the
meantime you cannot use the swap partition(s)/file(s) involved in
suspending. Also in this case you must not use the filesystems
that were mounted before the suspend. In particular, you MUST NOT
MOUNT any journaled filesystems mounted before the suspend or they
will get corrupted in a nasty way."
-- kernel .config Hibernation (aka 'suspend to disk') help text
From this text I would like to see a 'mkswap -a' done in the
non-resume boot path to make sure that any prior hibernate is
invalidated so filesystem corruption cannot happen due to user
does a:
s2d -> normal boot -> write filesystem -> shutdown -> resume
sequence. Dunno if this has been addressed anywhere in the s2d /
resume scripts or documentation but it looks too scary to let users
even open the possibility. A 'mkswap -a' is fairly quick and
harmless in normal boot path to be unnoticeable? Thing is how to
flag not to do that on the resume boot path?
At least this issue is not slack-specific. It's a kernel function.
Quick thought is to mark s2d kernel with say 'linux-2.6.26.5-s2d'
and test for that trailing '-s2d' and do the mkswap -a if it's missing.
Safe option -- disabling resume prevents possible filesystem
corruption at cost of user perhaps losing work-in-progress? Think
I'd prefer to lose some work rather than the filesystem.
Or, have I misunderstood the risk to the filesystem here? Got another
box I might be able to test on too, as it has a little more swap than
RAM 4GB -- what could go wrong? :) Though it's split over two spindles.
Grant.
--
http://bugsplatter.id.au/
Grant
Sorry can't help with Toshiba lappy -- doesn't resume properly from
the:
echo disk > /sys/power/state
kernel command, so it seems pointless to go further with whatever pm-utils
does, unless I've missed something? The lappy seems to resume okay except
the NIC doesn't come back up, yet the dmesg says all was well on resume,
had debug turned on so it was fairly clear, I put the file here:
http://bugsplatter.id.au/kernel/boxen/toshi/dmesg-s2d-resume-2.6.26.5-s2d.gz
in case you're curious.
Grant.
--
http://bugsplatter.id.au/
PJ Beers
> I've just finished packaging pm-utils 1.2.2 for Slackware (unofficially,
> of course), and I'd like to get some more widespread testing with it.
> This new release automatically queries the HAL "quirks" database, so in
> theory, suspend/resume should work on almost all laptops with it.
[snip]
> Once it's installed, running "pm-suspend" as root should do a suspend
> to ram, and "pm-hibernate" should suspend to disk. Note that you
> must have a swap partition (or file, but partition is easier) which is
> large enough (2x ram is good here) and the relevant initrd lines and
> such for this to work. If you're not familiar with all of that, don't
> test pm-hibernate. [1]
[snip]
Hi, great to see these efforts for getting some suspend automation on
Slackware!
I tested both pm-suspend and pm-hibernate, and both worked properly (better
than with the hibernate-script I had installed). This on a Thinkpad t43p.
Incidentally, I also tested pm-utils with uswsusp (I installed uswsusp, and
added a text-file with SLEEP_MODULE=uswsusp in /etc/pm/config.d/ ),
pm-suspend and pm-suspend-hybrid, and these also worked as advertised.
Regards,
PJ
Robby Workman
Hrm, I'm surprised that was needed. Can you email the complete "lshal"
output to me, please? A general description of the hardware would be
good too (i.e. what you said above, just so I don't forget if the mail
gets unlinked with this thread) :-)
Mail address is in headers.
-RW
Robby Workman
IMHO, if a user chooses to boot in a "non-resume" mode, then that user
damn well better understand what he/she is doing (and risking). As I
understand it, that situation will never "just happen" (i.e. it will
not happen accidentally).
-RW
Robby Workman
This might give you some ideas if you're so inclined:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
-RW
Robby Workman
>
> Hi, great to see these efforts for getting some suspend automation on
> Slackware!
Well, I can't promise that it will ever reach a state where I can feel
confident recommending it for inclusion, but here's hoping. Even if it
doesn't, I plan to maintain unofficial packages until/unless something
better comes along.
> I tested both pm-suspend and pm-hibernate, and both worked properly (better
> than with the hibernate-script I had installed). This on a Thinkpad t43p.
For clarification, you did not have to pass any extra quirks on the
command line (IOW, you used only "pm-suspend" or "pm-hibernate") ?
The reason I ask is: I've already gotten one report where running with
no arguments didn't quite work out, but specifying additional quirks
on the command line worked fine. I've got a patch to hal-info queued
for that one already.
-RW
Grant
>On 2008-10-08, Grant <g_r_a...@dodo.com.au> wrote:
...
>> Right now you may boot without resuming and resume later but in the
>> meantime you cannot use the swap partition(s)/file(s) involved in
>> suspending. Also in this case you must not use the filesystems
>> that were mounted before the suspend. In particular, you MUST NOT
>> MOUNT any journaled filesystems mounted before the suspend or they
>> will get corrupted in a nasty way."
>>
>> -- kernel .config Hibernation (aka 'suspend to disk') help text
...
>> Or, have I misunderstood the risk to the filesystem here? Got another
>> box I might be able to test on too, as it has a little more swap than
>> RAM 4GB -- what could go wrong? :) Though it's split over two spindles.
>
>
>IMHO, if a user chooses to boot in a "non-resume" mode, then that user
>damn well better understand what he/she is doing (and risking). As I
>understand it, that situation will never "just happen" (i.e. it will
>not happen accidentally).
Okay -- it gave me quite a scare on first reading ;) To be honest I'm not
a fan of suspend or standby, it is not reliable on windoze (due to improper
network handling) and I've seen too many issues over the years thrashed out
on LKML.
As far as how easy it is to hose a filesystem, I agree if you bootup into
a default lilo stanza with the resume clause there should be no issue at
all. But I've seen these multi-boot options in other distros and it leaves
me wondering how safe they are in their boot menu options.
I suppose slackers are safer because it requires some thought to add this
option to lilo.
Grant.
--
http://bugsplatter.id.au/
Jim Diamond
> On Tue, 07 Oct 2008 20:38:16 +0000, Robby Workman <newsg...@rlworkman.net> wrote:
>
>>On 2008-10-06, Robby Workman <newsg...@rlworkman.net> wrote:
>>
>>> Package here:
>>> http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2-i486-1_rlw.tgz
>>> Sources here:
>>> http://rlworkman.net/pkgs/sources/12.1/pm-utils/
>>
>>
>>Update:
>>
>>http://rlworkman.net/pkgs/12.1/TESTING/pm-utils-1.2.2.1-i486-1_rlw.tgz
>>Sources in same place.
>
> Okay,I'm reading and learning more about suspend2disk (hibernate),
> and would like to know if you've considered this little gem:
>
> "In principle it does not require ACPI or APM, although for example
> ACPI will be used for the final steps when it is available. One
> of the reasons to use software suspend is that the firmware hooks
> for suspend states like suspend-to-RAM (STR) often don't work very
> well with Linux.
I wonder how recently that comment has been updated. I've been using
S2R flawlessly on a variety of laptops (8 or 9 different models) over
the last few years. I can't imagine that I've been unusually lucky.
Cheers.
Jim
Robby Workman
> On Wed, 08 Oct 2008 20:44:51 +0000, Robby Workman <newsg...@rlworkman.net> wrote:
>
>>IMHO, if a user chooses to boot in a "non-resume" mode, then that user
>>damn well better understand what he/she is doing (and risking). As I
>>understand it, that situation will never "just happen" (i.e. it will
>>not happen accidentally).
>
> Okay -- it gave me quite a scare on first reading ;) To be honest I'm not
> a fan of suspend or standby, it is not reliable on windoze (due to improper
> network handling) and I've seen too many issues over the years thrashed out
> on LKML.
Yeah, and while it's come a *long* way over the years, it's obviously
still not (and likely never will be) perfect. I've spent a bit of time
lately wading through hal-info source (creating patches in response to
feedback on all of this - adding new machine signatures and default
quirks and such), and it's a *lot* of information. There's not any
"standard" way to implement suspend/resume at a low level, and while
part of me wishes there *were* standards in place, my experience with
"standards" says that the people who write them lose sight of the fact
that they have to *implemented* in the real world, so maybe that's not
such a good idea either.
All that being said, I think the best we can hope for at this point
is to continue merging known-good quirks for machine signatures into
hal-info and hope that eventually the hardware manufacturers settle
into designs that either eliminate the need for quirks or make it so
that entire product lines (e.g. all Thinkpad T6x series) use the same
set of quirks. In some cases, this seems to be improving, but in
others, it seems to be getting worse...
> As far as how easy it is to hose a filesystem, I agree if you bootup into
> a default lilo stanza with the resume clause there should be no issue at
> all. But I've seen these multi-boot options in other distros and it leaves
> me wondering how safe they are in their boot menu options.
That seems to be the intent of the 00grub hook in pm-utils.
> I suppose slackers are safer because it requires some thought to add this
> option to lilo.
Indeed. There's only so far you can go in "braindead-proofing" before
things get unnecessarily complex.
-RW
Stephen Bloom
varying degrees of success on my Dell D820. Real catastrophies
on a regular basis with Slack 12.1 and the 2.6.24.5 kernel;
things *much* better with the 2.6.26.1 kernel.
So - couple of questions: what is the relationship between
your pm-utils and the TuxonIce stuff (in terms of safety,
functionality, etc)? How do I "bind" the pm-utilities
to the Klaptop buttons in KDE (if possible)?
I've gone through a fair amount of trauma messing around
with suspend/hibernate with this machine; my ldconfig
mystery (eventually "solved" by blasting everything to
bedrock, repartitioning and reinstalling Slack 12.1)
occurred after a post-hibernation meltdown with the
2.6.24.5 kernel.
Steve
mister b
> I've gone through a fair amount of trauma messing around with
> suspend/hibernate with this machine; my ldconfig mystery (eventually
> "solved" by blasting everything to bedrock, repartitioning and
> reinstalling Slack 12.1) occurred after a post-hibernation meltdown with
> the 2.6.24.5 kernel.
been there with Mandriva on an R51...a guru in that ng suggested
disabling write caching IIRC...might be worth a google
PJ Beers
> On 2008-10-08, PJ Beers <pj_b...@hotmail.com> wrote:
>>
>> Hi, great to see these efforts for getting some suspend automation on
>> Slackware!
>
>
> Well, I can't promise that it will ever reach a state where I can feel
> confident recommending it for inclusion, but here's hoping. Even if it
> doesn't, I plan to maintain unofficial packages until/unless something
> better comes along.
At least the pm-utils framework seems more widespread and simple to maintain
than the hibernate-script or the laptop-mode-tools. And it would by nice
not to have to maintain my own packages... ...mean, thanks for the
good job :-)
>> I tested both pm-suspend and pm-hibernate, and both worked properly
>> (better than with the hibernate-script I had installed). This on a
>> Thinkpad t43p.
>
>
> For clarification, you did not have to pass any extra quirks on the
> command line (IOW, you used only "pm-suspend" or "pm-hibernate") ?
No quirks needed in any of the tests. To be precise: I tested
# pm-suspend
and
# pm-hibernate
and both worked out of the box with your package, without quirks.
Then, for good measure, I also tested pm-utils with SLEEP_MODULE=uswsusp:
# pm-suspend-hybrid
and
# pm-suspend
and both worked flawlessly (I did not bother to test pm-hibernate with
uswsusp).
PJ