lkml.org 
[lkml]   [2008]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-pm] [PATCH -mm] kexec jump -v9
Date
On Tuesday, 18 of March 2008, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, 14 of March 2008, Eric W. Biederman wrote:
> >
> >> > Still, it would be sufficient if we disconnected the drivers from the
> > hardware
> >> > and thus prevented applications from accessing that hardware.
> >>
> >> My gut feeling is that except for a handful of drivers we could even
> >> get away with simply implementing hot unplug and hot replug. Disks
> >> are the big exception here.
> >>
> >> Which suggests to me that it is at least possible that the methods we
> >> want for a kexec jump hibernation may be different from an in-kernel
> >> hibernation and quite possibly are easier to implement.
> >
> > I'm not sure about the "easier" part, quite frankly. Also, with our current
> > ordering of code the in-kernel hibernation will need the same callbacks
> > as the kexec-based thing. However, with the in-kernel approach we can
> > attempt (in the future) to be more ACPI compliant, so to speak, but with the
> > kexec-based approach that won't be possible.
> >
> > Whether it's a good idea to follow ACPI, as far as hibernation is concerned, is
> > a separate question, but IMO we won't be able to answer it without _lots_ of
> > testing on vaious BIOS/firmware configurations. Our experience so far
> > indicates that at least some BIOSes expect us to follow ACPI and misbehave
> > otherwise, so for those systems there should be an "ACPI way" available.
> > [Others just don't work well if we try to follow ACPI and those may be handled
> > using the kexec-based approach, but that doesn't mean that we can just ignore
> > the ACPI compliance issue, at least for now.]
>
> If we do use the ACPI S4 state I completely agree we should be at
> least spec compliant in how we use it.
>
> I took a quick skim through my copy of the ACPI spec so I could get a
> feel for this issue. Hibernation maps to the ACPI S4 state. The only
> thing we appear to gain from S4 is the ability to tell the BIOS (so it
> can tell a bootloader) that this was a hibernation power off instead
> of simply a software power off.
>
> It looks like entering the ACPI S4 state has a few advantages with
> respect to how the system wakes up. In general using the ACPI S5
> state (soft off) appears simpler, and potentially more reliable.
>
> The sequence we appear to want is:
> - Disconnecting drivers from devices.
> - Saving the image.
> - Placing the system in a low power or off state.
>
> - Coming out of the low power state.
> - Restoring the image.
> - Reconnecting drivers to devices.
> (We must assume the device state could have changed here
> no matter what we do)
>
> It is mostly a matter of where we place the code.
>
> Right now I don't see a limitation either with a kexec based approach
> or without one. Especially since the common case would be using
> the same kernel with the same drivers both before and after the
> hibernation event.
>
> The low power states for S4 seem to be just so that we can
> decide which devices have enough life that they can wake up
> the system. If we handle all of that as a second pass after
> we have the system in a state where we have saved it we should
> be in good shape.
>
> My inclination is to just use S5 (soft off).
>
> One of the cool things about hibernation to disk was that we were
> supposed to get the BIOS totally out of that path so we could get
> something that was rock solid and reliable. I don't see why we should
> use ACPI S4 when the BIOS doesn't seem to give us anything useful, and
> causes us headaches we should even consider using S4.
>
> Does using the S4 state have advantages that I currently do not
> see?
>
> Len? Rafael? Anyone?

Well, I've been saying that for I-don't-remember-how-long: on my box, if you
use S5 instead of entering S4, the fan doesn't work correctly after the
resume. Plain and simple.

Perhaps there's a problem with our ACPI drivers that causes this to happen,
but I have no idea what that can be at the moment.

Thanks,
Rafael


\
 
 \ /
  Last update: 2008-03-19 22:55    [from the cache]
©2003-2011 Jasper Spaans