Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

Matthew Garrett
2007-05-28T16:54:41Z

On Mon, May 28, 2007 at 12:43:36PM -0400, Alan Stern wrote:
> On Mon, 28 May 2007, Matthew Garrett wrote:
> > On Mon, May 28, 2007 at 12:09:30PM -0400, Alan Stern wrote:
> >
> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way. It's not a matter of races; the problem
> > > is that the kernel thread's job is to selectively suspend and resume
> > > devices. We don't want it doing this while a system sleep is in
> > > progress; it would (and in fact has, before the thread was made
> > > freezable) cause the sleep transition to abort.
> >
> > How does this work on PPC or APM systems?
>
> For hibernation it behaves the same as on other types of systems.
>
> For STR it generally works okay. There was one report of suspends
> aborting, and it looked like this was caused by selective resumes
> originating from userspace. This seemed to be unrelated to the kernel
> threads; apparently some program was running while the STR was in
> progress, and causing the problem. For example, the lsusb program will
> do a selective resume on every USB device as it scans through them all.
> However that's just a guess, we haven't fully resolved that bug report.
>
> The theoretical answer is that it behaves the way we want. The kernel
> thread does selective resumes in response to device requests. If such
> a request comes in while the system is asleep it will awaken the
> system; so it's only logical that a request coming in while the system
> is in the process of going to sleep should abort the suspend.

Ok, I guess I'm still not clear on this :) If it doesn't cause major
problems on Powermac or APM systems, why is freezing the thread
beneficial on ACPI systems?

--
Matthew Garrett | mjg59@srcf.ucam.org