Kyle Moffett wrote:
> On Feb 11, 2006, at 11:36, Jan Merka wrote:
>> I strongly disagree. I got suspend-to-RAM to work but its utility is
>> seriously limited by battery capacity. For example, on my laptop (Sony
>> VGN-B100B) with 1.5GB of RAM, a fully charged battery is drained in
>> about 18 hours if the laptop was suspended to RAM.
>
> Ick, that's kind of sucky hardware then. My PowerBook with 1GB RAM
> easily gets a week of sleep time off a fully charged battery; I don't
> think I've rebooted it _once_ in the last 2 months, I just leave it
> sleeping in my bag the whole time. Sony must be doing something wrong,
> because there's easily enough power in a single battery to keep RAM
> refreshed for a _long_ time.
>
>> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk
>> is _reliable_ and _safe_.
>
> As to the safety issue, I have my Apple Powerbook configured to suspend
> to RAM, and if it gets critically low on battery I have the firmware set
> to resume it automatically and my scripts shut it down so I don't lose
> data. Suspend-to-RAM when implemented properly _is_ reliable and safe,
> but it seems like a lot of hardware manufacturers get it wrong.
>
Hello,
I don't understand how a fundamental (good) debate of how
suspend to disk should be implemented in kernel, changed
into this one.
I don't care what Linus said... Suspend-to-disk is more
complicated than suspend-to-RAM. It is more complicated
since it provides more features. Suspend-to-RAM only stores
state, where Suspend-to-disk need to store the state
somewhere thus changing the initial state.
There is a long list of features available at
http://wiki.suspend2.net/FeatureUserRegister, which cannot
be provided using suspend-to-RAM, examples:
1. Store state on files - this allow you to resume your
machine into a different OS.
2. Encrypt state - this allow you to be sure that your data
is stored encrypted. (Yes... You can encrypt the memory...
but then you need a whole initramfs clone in order to allow
the user to specify how he want to encrypt/decrypt).
3. Network resume - this allow you to resume a network
machine (Not implemented yet, but cannot be done if
suspend-to-RAM is the sole implementation).
4. Support desktops/servers - this allow you to
suspend/resume hardware that is not designed to sleep, in
order to minimize downtime on power failure.
And another fact: Suspend-to-RAM implementation can be
derived form suspend-to-disk but not the other way around.
So let's invert the initial "fact"...
Suspend-to-RAM is basically for people that don't need the
full functionality of suspend-to-disk, after I got
suspend-to-disk to work reliably here (suspend2), I *NEVER*
use suspend-to-RAM.
Best Regards,
Alon Bar-Lev.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
