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