lkml.org 
[lkml]   [2008]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.


On Wed, 20 Feb 2008, Jesse Barnes wrote:
>
> The current callback system looks like this (according to Rafael and the last
> time I looked):
> ->suspend(PMSG_FREEZE)
> ->resume()
> ->suspend(PMSG_SUSPEND)
> *enter S3 or power off*
> ->resume()

Yes, it's very messy.

It's messy for a few different reasons:

- the one you hit: a driver actually has a really hard time telling what
PMSG_SUSPEND really means.

- more importantly, we generally don't want to "suspend/resume" the
hardware at all around a power-off, because we're going to resume with
the state at the time of the PMSG_FREEZE, which means that the hardware
has actually *changed* and been used in between!

that second case is very fundamental for things like USB devices, which in
theory you can hold alive over a real suspend event (ie a STR event), but
which absolutely MUST NOT be resumed over a suspend-to-disk event, because
all the low-level request state is bogus!

So the "->resume" really isn't a resume at all. It's much closer to a
"->reset".

Of course, the "solution" to this all right now is that we have to reset
everything even if it *is* a suspend event, so it basically means that STR
ends up using the much weaker model that snapshot-to-disk uses.

The fundamental problem being that the two really have nothing
what-so-ever to do with each other. They aren't even similar. Never were.

> And in the long term we could have:
> ->suspend()
> *enter S3*
> ->resume()

Yes, apart from all the complexities (suspend_late/resume_early). So in
reality it's more than that, but the suspend/resume things are clearly
nesting, and they have the potential to actually keep state around
(because we *know* this machine is not going to mess with the devices in
between).

IOW, here we actually can have as an option "assume the device is there
when you return".

> or:
> ->hibernate()
> *kexec to another kernel to save image*
> *power off*
> ->return_from_hibernate() (or somesuch)

Enough people don't trust kexec that I suspect the right thing simply is

->freeze() // stop dma, synchronize device state
*snapshot*
->unfreeze(); // resume dma
*save image*
[ optionally ->poweroff() ] // do we really care? I'd say no
*power off*
->restore() // reset device to the frozen one

which may have four entry-points that can be illogically mapped to the
suspend/resume ones like we do now, but they really have nothing to do
with suspending/resuming.

And notice how while "freeze/restore" kind of pairs like a
"suspend/resume", it really shouldn't be expected to realistically restore
the same state at all. The "restore" part is generally much better seen as
a "reset hardware" than a "resume" thing. Because we literally cannot
trust *anything* about the state since we froze it - we might have booted
a different OS in between etc. Very different from suspend/resume.

Linus


\
 
 \ /
  Last update: 2008-02-20 22:17    [W:0.154 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site