Date: Mon, 05 Mar 2007 13:19:37 -0800 From: Nate Lawson <nate@root.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-acpi@FreeBSD.org, Stefan Ehmann <shoesoft@gmx.net> Subject: Re: notebook freezes Message-ID: <45EC8969.8060405@root.org> In-Reply-To: <20070305142926.O2780@besplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> On Sun, 4 Mar 2007, Stefan Ehmann wrote:
>
>> On Sunday 04 March 2007 21:14, Nate Lawson wrote:
>>> Bruce Evans wrote:
>>>> [Trying to redirect this from current to acpi.]
>>>>
>>>> On Sun, 4 Mar 2007, Stefan Ehmann wrote:
>>>>> On Sunday 04 March 2007 13:27, Bruce Evans wrote:
>> ...
>>>>>> Oops. If suspend/resume clobbers the RTC state (which we already
>>>>>> have code
>>>>>> to restore), then it can clobber the RTC index (which even the
>>>>>> restoral
>>>>>> code assumes is unclobbered). Try this fix.
>> ...
>>>>>> I don't know how any of this works with ACPI. AFAIK (not far), the
>>>>>> resume
>>>>>> hook is only called for APM.
>>>>>
>>>>> Yes, rtc_restore() doesn't get called. So the patch changes nothing
>>>>> for me.
>>>
>>> Bruce's patch should work if you add "device pmtimer" to your kernel
>>> config. That will allow pmtimer_resume() to call timer_restore() which
>>> calls rtc_restore().
>>>
>>> If that works for you, Bruce can commit it modulo style bugs. ;-)
>
> Ha, some mailer mangled all the tabs inconsistently after I sent it. In
> the original version, there are only some style bugs in nearby comments
> that I wrote long ago. (The comments are misformatted and have rotted,
> but still provided hints that there are may be problems in the locking.
> I don't the current locking of individual RTC accesses since that just
> asks for races in sets of accesses.)
>
>> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was
>> already in my config). Probably the aftermath of the lunar eclipse :)
>>
>> On my second try, timer_restore really gets called and it also fixes my
>> problem.
>
> Could you add some RTC accesses to determine exactly what state is
> inconsistent? Something like the following:
>
> cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */
> printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg);
> rtc_reg = -1;
> cur_rtc_statusa = rtcin(RTC_STATUSA);
> printf(...);
> cur_rtc_statusb = rtcin(RTC_STATUSB);
> printf(...);
>
> Where should such cghecks be put in acpi code if a hook like pmtimer's
> is not available or not understood?
I don't understand. Every driver implements a DEVICE_RESUME() method
and that is responsible for figuring out the device-specific issues for
properly restoring the hw from any state, likely all state lost.
> 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.
> Someday I
> need to figure out why my laptop (HP nx6325) clobbers the time when
> its lid is closed. Suspend stuff mostly doesn't doesn't work. In
> particular, closing the lid doesn't even turn off the screen, but it
> does clobber the time given by the acpi timecounter by almost exactly
> 1 second. The TSC timecounter doesn't lose like this but it loses in
> other ways. Opening the lid doesn't change the time. I don't have
> pmtimer configured, but pmtimer would mess up the time even more because
> the RTC drifts relative to the correct time and inittodr() doesn't
> sync with the RTC so it is always off by an average of -0.5 seconds.
No idea -- is something running in SMM for a long time? I seem to
remember you had access to an oscilloscope. Check out the cpu pin
SMACT# when you close the lid.
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45EC8969.8060405>