From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org,
Pekka Enberg <penberg@cs.helsinki.fi>,
Johannes Berg <johannes@sipsolutions.net>,
Pavel Machek <pavel@ucw.cz>,
Nigel Cunningham <nigel@nigel.suspend2.net>
Subject: Re: Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy))
Date: Thu, 3 May 2007 19:17:23 +0200 [thread overview]
Message-ID: <200705031917.24417.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0705030946400.3548-100000@iolanthe.rowland.org>
On Thursday, 3 May 2007 16:00, Alan Stern wrote:
> On Wed, 2 May 2007, Johannes Berg wrote:
>
> > On Wed, 2007-05-02 at 11:16 +0200, Pavel Machek wrote:
> >
> > > Well... the powerdown during hibernation... does not have _anything_
> > > to do with snapshot/restore. It is really a very deep sleep; similar
> > > to soft powerdown, but not quite.
>
> Is this really a good idea?
>
> For that matter, what are the differences among the various sorts of
> poweroff?
>
> Which devices remain minimally powered for wakeup purposes?
>
> Anything else?
>
> In fact, shouldn't the poweroff at the end of a hibernate be exactly the
> same as a normal non-hibernate poweroff?
Not quite (see (*) below).
> Aren't drivers required to assume (during the processing after the snapshot
> has been restored) that power could have been lost and devices might need to
> be completely reinitialized?
>
> We are letting ourselves in for problems if we say that when the snapshot
> is restored, devices may or may not need to be reinitialized.
Agreed.
> Drivers might not be able to tell which, so they would have to reinitialize
> regardless, losing any advantage. Even worse, the device may _appear_ not
> to need reinitialization because the firmware (BIOS) has already
> initialized it but left it in a state that's useless for the kernel's
> purposes. (That's part of the reason why PRETHAW was added.)
Yes.
> If the only remaining difference between poweroff for hibernate and normal
> poweroff is which wakeup devices will function, then it seems pointless.
No, this is not the only difference (*).
> Why shouldn't the same devices work for wakeup from hibernate and wakeup
> from normal poweroff?
>
> Or have I misunderstood something and is this all nonsense?
The problem, generally speaking, is that we have to prepare devices for waking
up the system. On an ACPI system this is done, among other things, by
executing the devices' _PSW control methods after the system-level _PTS method
has run. For this purpose the devices must be in (low) power states from which
the wake is possible, so in particular they must not be powered off. Later, by
making the platform enter the suspend-to-disk (ACPI S4) state we prevent it
from powering off the wake-up devices, among other things.
That's why I'm thinking that it might be a good idea to do a
suspend-before-poweroff, but it doesn't mean that device drivers would be
allowed to make any assumptions regarding the state of the device after the
resume. IMO, if this is a resume from disk, devices should be initialized from
scratch.
(*) Another issue is that, for example, on my notebook the status of the AC
power supply (and sometimes of the battery too) is not reported correctly by
the platform after the resume if the suspend-to-disk (ACPI S4) state has not
been entered during the hibernation. I don't understand why this happens, but
I'm going to find out.
Greetings,
Rafael
next prev parent reply other threads:[~2007-05-03 17:17 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070425072350.GA6866@ucw.cz>
[not found] ` <Pine.LNX.4.64.0704251239110.8406@vaio.localdomain>
[not found] ` <alpine.LFD.0.98.0704251252070.9964@woody.linux-foundation.org>
[not found] ` <20070425202741.GC17387@elf.ucw.cz>
[not found] ` <alpine.LFD.0.98.0704251332090.9964@woody.linux-foundation.org>
[not found] ` <20070425214420.GG17387@elf.ucw.cz>
[not found] ` <alpine.LFD.0.98.0704251515140.9964@woody.linux-foundation.org>
[not found] ` <1177540027.5025.87.camel@nigel.suspend2.net>
[not found] ` <alpine.LFD.0.98.0704251550210.9964@woody.linux-foundation.org>
[not found] ` <1177583998.6814.42.camel@johannes.berg>
[not found] ` <20070426113005.GU17387@elf.ucw.cz>
2007-04-26 16:31 ` suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy) Johannes Berg
2007-04-26 18:40 ` Rafael J. Wysocki
2007-04-26 18:40 ` Johannes Berg
[not found] ` <1177612802.6814.121.camel@johannes.berg>
2007-04-26 19:02 ` Rafael J. Wysocki
[not found] ` <200704262102.38568.rjw@sisk.pl>
2007-04-27 9:41 ` Johannes Berg
[not found] ` <1177666915.7828.35.camel@johannes.berg>
2007-04-27 10:09 ` Johannes Berg
2007-04-27 10:18 ` Rafael J. Wysocki
[not found] ` <200704271218.07120.rjw@sisk.pl>
2007-04-27 10:19 ` Johannes Berg
[not found] ` <1177669179.7828.53.camel@johannes.berg>
[not found] ` <200704271409.56687.rjw@sisk.pl>
2007-04-27 12:07 ` Johannes Berg
2007-04-27 12:09 ` Rafael J. Wysocki
2007-04-29 12:48 ` [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) R. J. Wysocki
2007-04-29 12:53 ` Rafael J. Wysocki
2007-04-30 8:29 ` Johannes Berg
2007-04-30 14:51 ` Rafael J. Wysocki
2007-04-30 14:59 ` Johannes Berg
2007-05-01 14:05 ` Rafael J. Wysocki
2007-05-01 22:02 ` Rafael J. Wysocki
2007-05-02 5:13 ` Alexey Starikovskiy
2007-05-02 13:42 ` Rafael J. Wysocki
2007-05-02 14:11 ` Alexey Starikovskiy
2007-05-02 19:26 ` ACPI code in platform mode hibernation code paths (was: Re: [PATCH] swsusp: do not use pm_ops) Rafael J. Wysocki
[not found] ` <200705022126.47897.rjw@sisk.pl>
2007-05-03 22:48 ` Pavel Machek
[not found] ` <20070503224807.GD13426@elf.ucw.cz>
2007-05-03 23:14 ` Rafael J. Wysocki
2007-05-04 10:54 ` Johannes Berg
[not found] ` <1178276072.7408.7.camel@johannes.berg>
2007-05-04 12:08 ` Pavel Machek
[not found] ` <20070504120802.GF13426@elf.ucw.cz>
2007-05-04 12:29 ` Rafael J. Wysocki
2007-05-02 8:21 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) Johannes Berg
2007-05-02 9:02 ` Rafael J. Wysocki
2007-05-02 9:16 ` Pavel Machek
2007-05-02 9:25 ` Johannes Berg
2007-05-03 14:00 ` Alan Stern
2007-05-03 17:17 ` Rafael J. Wysocki [this message]
2007-05-03 18:33 ` Alan Stern
2007-05-03 19:47 ` Rafael J. Wysocki
2007-05-03 19:59 ` Alan Stern
2007-05-03 20:21 ` Rafael J. Wysocki
2007-05-04 14:40 ` Alan Stern
2007-05-04 20:20 ` Rafael J. Wysocki
2007-05-04 20:21 ` Johannes Berg
2007-05-04 20:55 ` Pavel Machek
2007-05-04 21:08 ` Johannes Berg
2007-05-04 21:15 ` Pavel Machek
2007-05-04 21:53 ` Rafael J. Wysocki
2007-05-04 21:53 ` Johannes Berg
2007-05-04 22:25 ` Rafael J. Wysocki
2007-05-05 15:52 ` Alan Stern
2007-05-07 1:16 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: ...) David Brownell
2007-05-07 21:00 ` Rafael J. Wysocki
2007-05-07 21:45 ` David Brownell
2007-05-07 22:16 ` Rafael J. Wysocki
2007-05-09 19:23 ` David Brownell
2007-05-04 21:06 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) Rafael J. Wysocki
2007-05-04 20:58 ` Pavel Machek
2007-05-04 21:24 ` Rafael J. Wysocki
2007-05-05 16:19 ` Alan Stern
2007-05-05 17:46 ` Rafael J. Wysocki
2007-05-05 21:42 ` Alan Stern
2007-05-05 22:14 ` Rafael J. Wysocki
2007-05-04 21:40 ` David Brownell
2007-05-04 22:19 ` Rafael J. Wysocki
2007-05-07 1:05 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: ...)) David Brownell
2007-05-05 16:08 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) Alan Stern
2007-05-05 17:50 ` Rafael J. Wysocki
2007-05-05 21:43 ` Alan Stern
2007-05-05 22:16 ` Rafael J. Wysocki
2007-05-07 1:31 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: ...) David Brownell
2007-05-07 16:33 ` Alan Stern
2007-05-07 20:49 ` Pavel Machek
2007-05-07 21:38 ` Alan Stern
2007-05-08 0:30 ` Pavel Machek
2007-05-03 20:33 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) David Brownell
2007-05-03 20:33 ` David Brownell
2007-05-03 20:51 ` Rafael J. Wysocki
2007-05-04 14:51 ` Alan Stern
2007-05-04 14:56 ` Johannes Berg
2007-05-04 20:27 ` Rafael J. Wysocki
2007-05-04 22:00 ` David Brownell
2007-05-05 15:49 ` Alan Stern
2007-05-07 1:10 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: ...)) David Brownell
2007-05-07 18:46 ` Alan Stern
2007-05-07 21:29 ` Rafael J. Wysocki
2007-05-07 22:22 ` Alan Stern
2007-05-07 22:47 ` Rafael J. Wysocki
2007-05-08 14:56 ` Alan Stern
2007-05-08 19:59 ` Rafael J. Wysocki
2007-05-08 21:26 ` Alan Stern
2007-05-09 8:17 ` Pavel Machek
2007-05-09 15:21 ` Alan Stern
2007-05-09 19:35 ` David Brownell
2007-05-09 20:04 ` Alan Stern
2007-05-09 20:21 ` David Brownell
2007-05-10 15:17 ` Alan Stern
2007-05-09 21:07 ` Pavel Machek
2007-05-07 21:43 ` David Brownell
2007-05-07 22:41 ` Alan Stern
2007-05-03 22:18 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) Pavel Machek
2007-05-04 14:57 ` Alan Stern
2007-05-04 20:50 ` Rafael J. Wysocki
2007-05-04 20:49 ` Johannes Berg
2007-05-04 21:11 ` Rafael J. Wysocki
2007-05-04 21:23 ` Johannes Berg
2007-05-04 21:55 ` Rafael J. Wysocki
2007-05-04 21:54 ` Johannes Berg
2007-05-04 22:21 ` Rafael J. Wysocki
2007-05-05 15:37 ` Alan Stern
2007-05-05 18:49 ` Rafael J. Wysocki
2007-05-05 21:44 ` Alan Stern
2007-05-05 22:36 ` Rafael J. Wysocki
2007-05-06 22:01 ` Alan Stern
2007-05-06 22:31 ` Rafael J. Wysocki
2007-05-07 1:37 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: ..) David Brownell
2007-05-08 2:57 ` Greg KH
2007-05-07 8:51 ` Re: [PATCH] swsusp: do not use pm_ops (was: Re: suspend2 merge (was: Re: CFS and suspend2: hang in atomic copy)) Johannes Berg
2007-05-04 22:12 ` David Brownell
2007-05-04 22:31 ` Rafael J. Wysocki
2007-05-05 16:15 ` Alan Stern
2007-05-02 13:43 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705031917.24417.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=johannes@sipsolutions.net \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nigel@nigel.suspend2.net \
--cc=pavel@ucw.cz \
--cc=penberg@cs.helsinki.fi \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox