notebook freezes

Bruce Evans bde at zeta.org.au
Mon Mar 5 04:21:06 UTC 2007


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?

Where do timer updates on suspend/resume happen for 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.

Bruce


More information about the freebsd-acpi mailing list