lkml.org 
[lkml]   [2007]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Hibernation considerations
    Date
    On Monday, 16 July 2007 14:38, Jim Crilly wrote:
    > On 07/16/07 02:06:27PM +0200, Rafael J. Wysocki wrote:
    > > On Monday, 16 July 2007 01:49, david@lang.hm wrote:
    > > > On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
    > > >
    > > > > On Monday, 16 July 2007 00:42, david@lang.hm wrote:
    > > > >> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
    > > > >>
    > > > >>> On Sunday, 15 July 2007 22:13, david@lang.hm wrote:
    > > > >>>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
    > > > >>>>
    > > > >>>>> The ACPI specification requires us to invoke some global ACPI methods
    > > > >>>>> during the hibernation and during the restore. Moreover, the ordering of
    > > > >>>>> code related to these ACPI methods may not be arbitrary (eg. some of
    > > > >>>>> them have to be executed after devices are put into low power states etc.).
    > > > >>>>
    > > > >>>> for a pure hibernate mode, you will be powering off the box after saving
    > > > >>>> the suspend image. why are there any special ACPI modes involved?
    > > > >>>
    > > > >>> Because, for example, on my machine the status of power supply (present
    > > > >>> vs not present) is not updated correctly after the restore if ACPI callbacks
    > > > >>> aren't used during the hibernation. That's just experience and it's in line
    > > > >>> with the ACPI spec.
    > > > >>
    > > > >> so if a machine is actually powered off the /dev/suspend process won't
    > > > >> work?
    > > > >
    > > > > No, it sort of works as usual, but after the restore the platform is not in the
    > > > > correct state.
    > > >
    > > > this is not hibernate as I and many others are thinking of it.
    > > >
    > > > hibernate as we are thinking would work on basicly any hardware, including
    > > > things with no ACPI or power savings support. and the system could be in
    > > > hibernate mode for any time period.
    > > >
    > > > for that matter, after a system is put into hibernate mode the system
    > > > could be completely disassembled and any components replaced and the
    > > > system would work after a resume (assuming you still have access to the
    > > > suspend image)
    > >
    > > Well, this is not how ACPI defines the S4 sleep state. If the system is in
    > > S4, that corresponds to our hibernation, you are _not_ allowed to disassemble
    > > it.
    > >
    > > I've just done an experiment on my test desktop. I had enabled suspend support
    > > in the CMOS setup and afterwards I made Linux hibernate in the "platform" mode.
    > > Then, when the system was powred on, the BIOS showed me a nice "Resume from
    > > hibernation" screen that is not normally displayed during boot. This clearly
    > > means that some information has been preserved by the platform across the
    > > hibernate/restore cycle. We are supposed to handle that.
    > >
    >
    > What I believe he's getting at is that Linux hibernation shouldn't be tied
    > to any ACPI states. Yes, when available and working most people will want
    > to enter ACPI S4 but we should still have the option of doing a normal
    > poweroff. With the latter method it would look just like regular power off/on
    > cycle to the firmware. And that would definitely be useful for things like
    > working around buggy ACPI implementations or supporting platforms that don't
    > do ACPI at all. That is the difference between the platform and shutdown
    > options in /sys/power/disk, isn't it?

    Yes, but this is not my point.

    The point is that there are systems that _require_ the ACPI handling to work
    correctly after the restore and we need to that _that_ into consideration.

    IOW, there are poeple for whom the non-ACPI framework won't work as expected.

    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 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: 2007-07-16 17:23    [W:3.338 / U:1.368 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site