Date: Wed, 7 Mar 2007 16:14:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org, Stefan Ehmann <shoesoft@gmx.net> Subject: Re: notebook freezes Message-ID: <20070307155745.X28283@delplex.bde.org> In-Reply-To: <200703061310.11346.jhb@freebsd.org> References: <200703011612.07110.shoesoft@gmx.net> <200703061027.25387.jhb@freebsd.org> <45ED9D71.5040904@root.org> <200703061310.11346.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Mar 2007, John Baldwin wrote: > On Tuesday 06 March 2007 11:57, Nate Lawson wrote: >> John Baldwin wrote: >>> On Monday 05 March 2007 16:19, Nate Lawson wrote: >>>>> Where do timer updates on suspend/resume happen for acpi? >>>> pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from >>>> both apm and acpi. >>> >>> pmtimer should be on by default in 7 I think. It is for amd64 already > IIRC, >>> just not for i386. Actually, for amd64, neither pmtimer nor suspend/resume methods in clock.c exist. >> Yeah, I see it in GENERIC. His issue was just driver error with the >> patch. The patch has been committed. > > I'm saying in general that pmtimer should really not be optional. It's a > small amount of code, so there isn't really anything gained by leaving it > out. I agree. I forgot to ask about the problem of interrupts racing with resume. What stops an interrupt occurring before the resume methods (the device method and all the ones above it) complete? I don't know of any locking to prevent this or any way to detect this short of checking for magic garbage in device registers that have garbage in them because the registers are unmapped or just clobbered. Can suspend happen asynchronously, so that it is possible for resume to deadlock on a resource locked by somthing which was interrupted for the suspend? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070307155745.X28283>