Clearly just as important to testers - headsup that swsup is around :)
--
Colin Charles, http://www.bytebot.net/
--- Begin Message ---
As the rawhide kernel has been pretty boring and uneventful
so far, this last day or two, Jeremy Katz and I managed to
beat suspend to disk support into shape.
The current rawhide kernel (2.6.12-1.1482 and above) now has
suspend to disk support enabled using the in-kernel software suspend.
At this early stage, play with this at your own risk! Doing the wrong
things (or even the right things at the wrong time) can result in
irrecoverable data loss.
If the above warning hasn't put you off testing, you're probably
wondering how to play with this potential datamuncher.
1. Make sure you have a swap partition.
(if you have >1, it'll only use the first one, so make sure
its at least as big as your RAM). Whilst suspend does evict
some non-essential things from memory before it suspends,
it can still end up with quite a bit to write out.
2. Make sure the swap partition is enabled.
(cat /proc/swaps if you're unsure)
3.
echo platform > /sys/power/disk
echo disk > /sys/power/state
(This will all be done in a much more user friendly way for the FC5 release)
4. Stare at the gobs of info scrolling up the screen.
(This will all be cleared up eventually, but for now it's
potentially useful for debugging).
5. After a while, your computer should turn itself off.
When you turn it back on, the initrd will detect the resume
partition and attempt to resume from it.
Then presto, you're back where you were.
Some caveats noted so far:
- Some device drivers don't wake up correctly.
So things like your ethernet may need an rmmod/modprobe after
resuming, to get things working again until the driver gets fixed.
Please report these types of bugs.
- *NEVER*, *EVER*, write into /sys/power/resume after you've booted.
This is going to have to be made safe at some point. Right now, doing
that whilst you've got partitions mounted is a guaranteed way to say
goodbye to some files. The good news, is that this is the only
way I've found so far to corrupt data.
- If you suspend and then don't go back into the same kernel, you won't be
able to resume and your swap won't be initialized. Be sure that you run
mkswap on your swap partition before booting back to the swsusp kernel.
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165863)
- Swap that's referenced with LABEL= in /etc/fstab doesn't currently work for
resume. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165864)
- We haven't tried doing this with X running :) It's likely to work better if
you switch to a tty first.
- Swap on RAID devices *should* work, but is untested so far.
- Changing hardware (adding/removing PCI cards/CPUs etc) is going to bring
you a world of pain. swsusp does detect some of the simpler cases
and will refuse to resume if the amount of RAM differs etc, but some
others won't be detected. In particular things like USB could be
problematic.
- If you suspend and then want to boot normally (ie, without resuming), add
"noresume" to your boot command line.
Finally, hopefully this will work out, and we'll get whatever bugs turn
up squished quickly. However at this point, there's no guarantee that
this will make it into FC5. It all depends on user feedback.
So test, and report any bugs in bugzilla. And if by some miracle it
all works perfectly for you, we'd love to hear success stories too
on fedora-devel list.
Dave
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--- End Message ---
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list