Date: Thu, 8 Mar 2007 10:23:45 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Stefan Ehmann <shoesoft@gmx.net> Subject: Re: notebook freezes Message-ID: <200703081023.45976.jhb@freebsd.org> In-Reply-To: <20070308183232.F3026@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <200703071053.45439.jhb@freebsd.org> <20070308183232.F3026@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 08 March 2007 02:32, Bruce Evans wrote: > 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(). Since the clocks aren't a new-bus device anyway, we can make them explicitly be suspended and resumed while interrupts are disabled for x86. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703081023.45976.jhb>