On Tuesday, 17 July 2007 22:18, david@xxxxxxx wrote: > On Tue, 17 Jul 2007, Rafael J. Wysocki wrote: > > > On Tuesday, 17 July 2007 19:06, david@xxxxxxx wrote: > >> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote: > >> > >>> On Tuesday, 17 July 2007 17:29, david@xxxxxxx wrote: > >>>> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote: > >>>> > >>>>> On Tuesday, 17 July 2007 16:15, Alan Stern wrote: > >>>>>> On Mon, 16 Jul 2007 david@xxxxxxx wrote: > >>>>>> > >>>>>>>> I agree, it would be good to have a non-ACPI-specific hibernation mode, > >>>>>>>> something which would look to ACPI like a normal shutdown. But I'm not > >>>>>>>> so sure this is possible. > >>>>>>> > >>>>>>> why would it not be possible? > >>>>>> > >>>>>>> I can't think of anything much more frustrating then thinking that I > >>>>>>> suspended a system and then discovering that becouse the battery went dead > >>>>>>> (a complete power loss) that the system wouldn't boot up properly. to me > >>>>>>> this would be a fairly common condition (when I'm mobile I use the machine > >>>>>>> until I am out of battery, then stop and it may be a long time (days) > >>>>>>> before I can charge the thing up again) this would not be a reliable > >>>>>>> suspend as far as I'm concerned. > >>>>>>> > >>>>>>> for suspend-to-ram you have to worry about ACPI states and what you are > >>>>>>> doing with them, for suspend-to-disk you can ignore them and completely > >>>>>>> power the system off instead. > >>>>>> > >>>>>> If the only problem with doing this would be lack of wakeup support > >>>>>> then I'm all for it. There must be a lot of people who would like > >>>>>> their computers to hibernate with power drain as close to 0 as possible > >>>>>> and who don't care about remote wakeup. In fact they might even prefer > >>>>>> not to have wakeup support, so the computer doesn't resume at > >>>>>> unexpected times. > >>>>> > >>>>> I'm afraid of one thing, though. > >>>>> > >>>>> If we create a framework without ACPI (well, ACPI needs to be enabled in the > >>>>> kernel anyway for other reasons, like the ability to suspend to RAM) and then > >>>>> it turns out that we have to add some ACPI hooks to it, that might be difficult > >>>>> to do cleanly. > >>>> > >>>> doing suspend-to-ram should be orthoginal to doing hibernate-to-disk. some > >>>> people will want both, some won't. > >>>> > >>>> at the moment kexec doesn't work with ACPI, that is a limitation that > >>>> should be fixed, but makeing it able to work with ACPI enabled doesn't > >>>> mean that it needs to be changed to depend on ACPI and it especially > >>>> doesn't mean that it should pick up the limitations of the existing ACPI > >>>> based hibernation approaches. > >>>> > >>>> if there is no ACPI on the system it should work, if ther is ACPI on the > >>>> system it should still work. > >>>> > >>>>> Thus, it seems reasonable to think of the ACPI handling in advance. > >>>> > >>>> but don't become dependant on ACPI. > >>> > >>> Not dependent, but with the possibility of ACPI support taken into account. > >>> > >>> Arguably you can create a framework that, for example, will not allow the user > >>> to adjust the size of the image, but then adding such a functionality may > >>> require you to change the entire design. Same thing with ACPI. > >>> > >>> I would rather avoid such pitfalls, if I could. > >> > >> Ok, what is it that you think ACPI fundamentally changes in this process? > >> > >> keep in mind that we are not makeing the assumption that the hardware > >> will remain powered (even a little bit), or the assumption that nothing > >> else will run on the hardware (eliminating any possibility that the > >> hardware is in a known ACPI state) > > > > Well, first, the fact is that _some_ systems _will_ be powered while in > > hibernation (the majority of notebooks, for example) and you should assume > > that the platform _may_ retain some information accross the hibernation/restore > > cycle. In that case you _should_ _not_ trash the information retained by the > > platform. > > no, systems that remain powered while asleep are a different type of > suspend then ones that don't. > > > Now, with that in mind, ACPI requires us to make the system enter the S4 sleep > > state as a result of the hibernation procedure. In my opinion this may be done > > after saving the image, but still this means, for example, that the > > image-saving kernel needs to support ACPI. > > > > Next, during the restore, we should first check if the image is present (and > > valid) _without_ turning ACPI on (note that this is not done by the current > > hibernation code and that leads to strange problems on some systems). Then, > > if the image is present (and valid), we should first load it, jump to the > > hibernated kernel and _then_ turn ACPI on and execute the _BFS and > > _WAK ACPI global methods (again, this is not done by the current code in that > > order, which is wrong). Only after that is the hibernated kernel supposed to > > continue. > > > > [Please refer to section 15.3 of the 3.0b ACPI spec for details.] > > you are starting from the assumption that ACPI S4 mode should be used. > > I'm saying that a suspend that uses ACPI S4 mode is fundamentally > different from one that does a power off instead. It is different, but not fundamentally. > from my point of view the ACPI S4 sleep mode has far more in common with > suspend-to-ram then with the suspend-to-disk that I'm talking about > > non-ACPI hibernate > > since the box powers off > it uses zero power while suspended > another OS could be run before a resume > hardware can be swapped, suspend image could be sent around the world to be restored on another system. > restore makes no assumptions about the state of the hardware when it is restored > restore is slower (full BIOS boot is required) > should be able to work on just about any hardware (the limit is the ability to initialize the devices) > > > ACPI suspends > > since the box never completely powers off: > a complete power failure breaks the suspend > the OS must remain in control so other uses must be prevented. > hardware must remain in the ACPI state from suspend until restore. > restore can be faster (some initialization may be able to be skipped) > requires ACPI hardware support > > under the catagory of ACPI suspends you have > > fast suspend-to-ram (stop scheduling, put the CPU to sleep, as long as > the memory keeps getting refreshed) > slow suspend-to-ram (stop scheduling, put as much of the hardware as > possible to sleep, including spinning down disks and other things that > take a while to undo) > suspend-to-disk (stop scheduleing, copy the ram somewhere so that it > doesn't need to be refreshed, put everything into low-power mode) > > and there are probably quite a few others as well. but they are all in > the same family in that you have to worry about ACPI states, and they all > have the same restrictions on what can happen between suspend and resume > > the non-ACPI hibernate behaves very differently, and for some people (and > I think I am one of them) it will meet their needs better then _any_ of > the ACPI suspends. OTOH, there are many people who would want the ACPI suspends to be handled and they don't really care for the power-off-only hibernation. If you aren't going to support the ACPI hibernation, your framework will be incomplete and therefore not generally useful. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
