From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend Date: Mon, 28 May 2007 17:54:41 +0100 Message-ID: <20070528165441.GA1669@srcf.ucam.org> References: <20070528161242.GA1063@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: LKML , Pavel Machek , pm list List-Id: linux-pm@vger.kernel.org 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