[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1180341026.14749.12.camel@nigel.suspend2.net>
Date: Mon, 28 May 2007 18:30:26 +1000
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, Pavel Machek <pavel@....cz>,
Alan Stern <stern@...land.harvard.edu>,
Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before
hibernation/suspend
Hi.
On Sun, 2007-05-27 at 23:45 +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rjw@...k.pl>
> > >
> > > Use a hibernation and suspend notifier to disable the firmware requesting
> > > mechanism before a hibernation/suspend and enable it after the operation.
> >
> > This avoids the problem of .resume methods calling userspace while
> > userspace is frozen and a resulting hang, but does it actually result in
> > the drivers beginning to work again?
>
> Well, this was acutally invented before you've decided to remove the freezing
> of tasks from the suspend code path (which I think is a mistake, but that's
> only my personal opinion, so it doesn't matter very much ;-)) and I regard it
> as a workaround.
Suspend-to-ram code paths shouldn't assume userspace is unfrozen anyway.
Doesn't [u]swsusp have a code path like Suspend2 where we can suspend to
ram after writing the hibernation image? In that case, it will still be
possible that we seek to enter and leave S3 with processes frozen.
Apologies if anyone has already mentioned this - I'm just starting to
play catchup.
Regards,
Nigel
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists