Messages in this thread | | | Date | Wed, 20 Feb 2008 13:13:37 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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
| |