All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: David Brownell <david-b@pacbell.net>,
	Alexander Gran <alex@zodiac.dnsalias.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: fixing usb suspend/resuming
Date: Fri, 30 Jul 2004 08:51:16 +1000	[thread overview]
Message-ID: <1091141476.2703.47.camel@desktop.cunninghams> (raw)
In-Reply-To: <20040729223959.GF18623@elf.ucw.cz>

Hi.

On Fri, 2004-07-30 at 08:39, Pavel Machek wrote:
> > I'm assuming (and believe I have achieved) that the only process doing
> > anything significant is suspend, in which case the image isn't going to
> > get damaged.
> 
> Well, only suspend is doing something significant, but driver might
> take arbitrary time to do its DMA... Like
> 
> Freeing some memory... [write starts]
> Suspending devices... [but you did not suspend disk!]
> Atomic copy... [oops, that disk was *still* doing DMA]

Sorry. Should have mentioned that one of my freezer changes includes
running sync between freezing userspace and freezing the kernel threads,
that I double check there are no dirty buffers afterwards and wait on
the completion of all suspend's I/O between after each part of the image
is written/read (have to be paranoid because of the way I reuse LRU
pages).

> > > need something like
> > > 
> > > suspend_fast_ill_resume_you_soon().
> > 
> > Don't understand what you're saying here, sorry.
> 
> Well, I believe we really need to suspend *all* devices. We just do
> not need to spin the disks down and make screens blank; we still need
> drivers to be stopped so that no activity happens during atomic copy.

Ah with you now. The typo got me (_ill_).


  reply	other threads:[~2004-07-29 22:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200405281406.10447@zodiac.zodiac.dnsalias.org>
     [not found] ` <40B74FC2.8000708@pacbell.net>
2004-06-01 14:14   ` fixing usb suspend/resuming Alexander Gran
2004-07-17 17:32     ` David Brownell
2004-07-19  7:27       ` Alexander Gran
2004-07-21  5:05         ` David Brownell
2004-07-29  8:35           ` Pavel Machek
2004-07-29 12:17             ` Nigel Cunningham
2004-07-29 12:51               ` Oliver Neukum
2004-07-29 22:15                 ` Nigel Cunningham
2004-07-29 14:07               ` David Brownell
2004-07-29 21:02               ` Pavel Machek
2004-07-29 22:26                 ` Nigel Cunningham
2004-07-29 22:39                   ` Pavel Machek
2004-07-29 22:51                     ` Nigel Cunningham [this message]
2004-07-29 14:16             ` David Brownell

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=1091141476.2703.47.camel@desktop.cunninghams \
    --to=ncunningham@linuxmail.org \
    --cc=alex@zodiac.dnsalias.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.