notebook freezes
John Baldwin
jhb at freebsd.org
Wed Mar 7 16:24:42 UTC 2007
On Wednesday 07 March 2007 00:14, Bruce Evans wrote:
> 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.
Hmm, well that should be fixed.
> >> 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?
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.
--
John Baldwin
More information about the freebsd-acpi
mailing list