linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: David Brownell <david-b@pacbell.net>
Cc: Paul Mackerras <paulus@samba.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Pavel Machek <pavel@ucw.cz>
Subject: Re: Totally broken PCI PM calls
Date: Tue, 12 Oct 2004 11:24:43 +1000	[thread overview]
Message-ID: <1097544283.3301.20.camel@desktop.cunninghams> (raw)
In-Reply-To: <200410111437.17898.david-b@pacbell.net>

Hi.

On Tue, 2004-10-12 at 07:37, David Brownell wrote:
> On Monday 11 October 2004 2:17 pm, Nigel Cunningham wrote:
> > On Tue, 2004-10-12 at 02:36, David Brownell wrote:
> > > I've made that point too.  STD is logically a few steps:  quiesce system,
> > > write image to swap, change power state.
> 
> I'm hoping you agree with that abbreviated summary of
> what's involved!  Pavel seemed to.  Of course the devil is
> in the details, which I hope to leave mostly to others ... ;)

It certainly fits for Pavel, but, I do have things slightly different,
so that don't have the maximum-image-size-is-half-of-RAM problem. At the
moment I do:

quiesce system & prepare metadata
suspend devices not used for writing the image or user I/O (this is just
seeking to remove any chance of them allocating memory, which might
strangle writing the image)
write LRU pages ('pageset 2')
suspend used devices
save CPU context & make atomic copy of remaining pages
resume used devices
save image
power down used devices
power down system/enter S4.

This is why I made that 'device tree' patch - so I could separate the
devices used for writing the image from those unused and treat them
separately. I'm pretty sure that I could get away with leaving the
unused ones alone until snapshot time, but it seems more ideal to me to
get them to save state and power down at the start, especially if you're
trying to suspend when the battery is low!

At the very least, I'd like to see that 'snapshot' state implemented
separately to the 'powerdown' state.

> Of course the ACPI spec muddies the water by talking about two
> different states called "S4":  "S4 Sleeping", which is what I was
> talking about as G1/S4; and "S4 Non-Volatile Sleep" that's more
> what I've seen with swusp:  more like a G2 or G3 poweroff.

Okay. I've only looked at the ACPI spec occasionally, and have generally
just followed the lead of Patrick and Pavel in implementing ACPI support
in s-t-d.

> I'm willing to believe that there are systems on which swsusp
> tells drivers a less confusing story ... but I don't seem to have
> tested with those!

:> I'm confused by all these changes; no wonder drivers are!

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.


  parent reply	other threads:[~2004-10-12  1:24 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-11  0:45 Totally broken PCI PM calls Benjamin Herrenschmidt
2004-10-11  2:41 ` Linus Torvalds
2004-10-11  3:42   ` Paul Mackerras
2004-10-11  4:04     ` Linus Torvalds
2004-10-11  4:24       ` Paul Mackerras
2004-10-11  9:57         ` Pavel Machek
2004-10-11 14:42         ` Linus Torvalds
2004-10-11 14:56           ` suspend-to-RAM [was Re: Totally broken PCI PM calls] Pavel Machek
2004-10-11 15:30             ` Linus Torvalds
2004-10-11 17:39               ` Olivier Galibert
2004-10-11 18:21                 ` Pavel Machek
2004-10-11 15:53             ` Brice Goglin
2004-10-11 16:17               ` Pavel Machek
2004-10-11 17:09                 ` Brice Goglin
2004-10-11 18:23                   ` Pavel Machek
2004-10-11 18:40                     ` Brice Goglin
2004-10-11 16:47         ` Totally broken PCI PM calls David Brownell
2004-10-11 22:28           ` Benjamin Herrenschmidt
2004-10-11 22:58             ` Dmitry Torokhov
2004-10-11 23:08               ` Benjamin Herrenschmidt
2004-10-12  3:00                 ` David Brownell
2004-10-12  4:09                   ` Dmitry Torokhov
2004-10-12 16:56                     ` David Brownell
2004-10-12  9:27             ` Russell King
2004-10-12 11:24               ` Benjamin Herrenschmidt
2004-10-11  4:25     ` Linus Torvalds
2004-10-11 10:18       ` Pavel Machek
2004-10-11 10:54         ` Benjamin Herrenschmidt
2004-10-11 16:01         ` Linus Torvalds
2004-10-15 13:59           ` Pavel Machek
2004-10-15 15:56             ` Linus Torvalds
2004-10-24 20:58               ` Pavel Machek
2004-10-24 21:18                 ` Linus Torvalds
2004-10-11 16:36     ` David Brownell
2004-10-11 21:17       ` Nigel Cunningham
2004-10-11 21:37         ` David Brownell
2004-10-11 22:12           ` Stefan Seyfried
2004-10-12  2:59             ` David Brownell
2004-10-12  8:54               ` Pavel Machek
2004-10-12 10:32                 ` Stefan Seyfried
2004-10-12 18:28                 ` David Brownell
2004-10-12 20:28                   ` Stefan Seyfried
2004-10-13 13:34                     ` David Brownell
2004-10-12  1:24           ` Nigel Cunningham [this message]
2004-10-12  8:53           ` Pavel Machek
2004-10-12 18:52             ` David Brownell
2004-10-12 19:50               ` Pavel Machek
2004-10-12 22:13               ` Benjamin Herrenschmidt
2004-10-12 22:35                 ` David Brownell
2004-10-11 22:26       ` Benjamin Herrenschmidt
2004-10-11  3:45   ` Benjamin Herrenschmidt
2004-10-11  4:08     ` Linus Torvalds
2004-10-11  4:23       ` Benjamin Herrenschmidt
2004-10-11  4:32         ` Linus Torvalds
2004-10-11  4:55           ` Benjamin Herrenschmidt
2004-10-11 16:15             ` David Brownell
2004-10-11 22:22               ` Benjamin Herrenschmidt
2004-10-12  2:46                 ` David Brownell
2004-10-12  4:02                   ` Benjamin Herrenschmidt
2004-10-12 10:49                     ` Nigel Cunningham
2004-10-12 11:27                       ` Benjamin Herrenschmidt
2004-10-12 11:38                         ` Nigel Cunningham
2004-10-12 11:51               ` Pavel Machek
2004-10-11 10:08     ` Pavel Machek
2004-10-11  9:51 ` Pavel Machek

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=1097544283.3301.20.camel@desktop.cunninghams \
    --to=ncunningham@linuxmail.org \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@osdl.org \
    /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;
as well as URLs for NNTP newsgroup(s).