tomorrows rawhide kernel.

[Bart Vanbrabant]

Dave Jones wrote:

>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
>
>  
>
It works on my laptop. An Asus LD5800 with an athlon 64 proc but running
x86 fedora. I've suspended twice from gnome, one time without a flaw but
the second time my X went crazy. My screen jumped a bit to the right. So
the edge of my screen was somewhere on my screen but my mouse wasn't. So
I had to guess where I should click. When I just changed my resolution
with the utility in preferences my screen was normal for a short period.
After I killed X everything worked again.

I use driverloader to get my wireless to work. The run a process to be
able to configure you're card with you're browser. That process made the
kernel panic. When I stop the process it works fine.

Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050814/a614110c/attachment-0002.bin