Date: Thu, 8 Mar 2007 18:32:44 +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: <20070308183232.F3026@besplex.bde.org> In-Reply-To: <200703071053.45439.jhb@freebsd.org> References: <200703011612.07110.shoesoft@gmx.net> <200703061310.11346.jhb@freebsd.org> <20070307155745.X28283@delplex.bde.org> <200703071053.45439.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Mar 2007, John Baldwin wrote: > On Wednesday 07 March 2007 00:14, Bruce Evans wrote: >> 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? > > I don't think there is stuff in there to protect against locks being held. > However, each device is supposed to turn its device off in it's > device_suspend() method and then turn it back on in device_resume() which > should resolve problems with garbage registers and spurious interrupts. pmtimer doesn't do this of course. Turning of RTC interrupts is easy, but turning off i8254 interrupts seems to require bus_teardown_intr(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070308183232.F3026>