Date: 18 Dec 1998 13:19:48 -0800 From: Matt Braithwaite <mab@alink.net> To: Mike Smith <mike@smith.net.au> Cc: mobile@FreeBSD.ORG Subject: Re: APM can suspend right after resume without updating clock Message-ID: <86btl1b11n.fsf@zildjian.hq.alink.net> In-Reply-To: Mike Smith's message of "Thu, 17 Dec 1998 18:16:58 -0800" References: <199812180216.SAA00613@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "MS" == Mike Smith <mike@smith.net.au> writes:
>> would it be easy to update the clock before suspending?
MS> Ah, I think I see what you mean; the loss of the resume
MS> message means that the clock hasn't been updated.
exactly: this isn't just a theory; i verified that my clock was off by
around the amount of the first sleep (many hours); in other words when
it resumed the second time, the clock was set at what it was when i
suspended the first time. xntpd has a hard time recovering from
this. :-)
MS> Probably a better approach would simply be to reload the
MS> system clock from the RTC.
as nearly as i can tell, it does:
pl = splsoftclock();
inittodr(0); /* adjust time to RTC */
microtime(&resume_time);
tmp_time = time; /* because 'time' is volatile */
timevaladd(&tmp_time, &diff_time);
time = tmp_time;
splx(pl);
the more i read, the more puzzled i get.
>> could suspending on low battery be left up to user code?
MS> What benefits would that bring? The events still need to be
MS> fetched in the kernel, and most event handling is pretty
MS> trivial...
well, maybe not much benefit for this particular situation. mostly, i
just hate polling. :-) i think it would be groovy if you could
select(2) on /dev/apm and get all the APM events going through your
system.
--
Matthew Braithwaite
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86btl1b11n.fsf>