On Tuesday, 17 July 2007 22:18, [email protected] wrote:
> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
>
> > On Tuesday, 17 July 2007 19:06, [email protected] wrote:
> >> On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
> >>
> >>> On Tuesday, 17 July 2007 17:29, [email protected] 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 [email protected] 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
-
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]
