![]() | |||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-02-12 09:54 [from the cache] ©2003-2008 | |||||||||||