Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
The abrupt merging of...
Posted Dec 16, 2009 2:35 UTC (Wed) by dlang (✭ supporter ✭, #313)
it's not merging tux on ice (I'm not sure that's a good thing anyway), but it is yet another case of him pointing out that this is not as complicated as it is being made out to be. If he does this enough something will snap (which may be Linus writing his own suspend code and merging it as on option, such things have happened before)
Posted Dec 16, 2009 3:01 UTC (Wed) by bojan (subscriber, #14302)
I'll also bet $5 that the whole thing would have been improved faster, had Linus decided to involve Nigel directly, by merging TuxOnIce.
Instead we have the uswsusp kludge (1000 moving parts or something?) and the old, slow and ugly swsusp. I hope Linus really gets annoyed one of these days :-)
Posted Dec 16, 2009 5:16 UTC (Wed) by cventers (subscriber, #31465)
Posted Dec 16, 2009 6:56 UTC (Wed) by bojan (subscriber, #14302)
Posted Dec 16, 2009 9:32 UTC (Wed) by michaeljt (subscriber, #39183)
For suspend to disk, I can see the difficulties - taking a clean snapshot of user space, where you
may have things like the X server doing things that user space shouldn't normally do, remembering
current kernel state and reconstructing it on next boot.
Posted Dec 16, 2009 10:46 UTC (Wed) by rsidd (subscriber, #2582)
On my current machine, suspend-to-RAM is all I need. Though suspend-to-disk (uswsusp, not tuxonice) works too.
Posted Dec 16, 2009 11:03 UTC (Wed) by michaeljt (subscriber, #39183)
Posted Dec 16, 2009 13:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Posted Dec 16, 2009 13:47 UTC (Wed) by michaeljt (subscriber, #39183)
Posted Dec 16, 2009 14:53 UTC (Wed) by mjg59 (subscriber, #23239)
Posted Dec 17, 2009 18:39 UTC (Thu) by michaeljt (subscriber, #39183)
Posted Dec 17, 2009 18:49 UTC (Thu) by mjg59 (subscriber, #23239)
Performing a full resume cycle is hard. You need to reprogram the memory controller, bring the
embedded controller up, dump values back into the thermal monitoring hardware and any number
of low-level initialisations. Only once that's been done does control get passed back to the OS,
which has absolutely no idea how any of that hardware works.
Posted Dec 16, 2009 11:59 UTC (Wed) by nhippi (subscriber, #34640)
And that is how things are done in ARM land. Some machines go even further
and power on hardware only when they are under use, rather than only
powering them down on explicit "suspend" event.
> and if there is too much hardware that you don't know you can reliably
> suspend, just failing? Or is it religious reasons of wanting to use BIOS
> ACPI code at all costs?
Using VGA bios for display adapters was kinda mandatory before Kernel
Modesetting. I believe on X86 it is kinda tricky to suspend some devices
using ACPI BIOS and others from kernel drivers. To efficiently use driver-
based suspend the ACPI usage should be stopped completely.
Posted Dec 16, 2009 20:42 UTC (Wed) by mgedmin (subscriber, #34497)
IIRC Matthew Garrett had a very nice explanation on his blog, but I cannot
find it at the moment.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds