From owner-freebsd-mobile Fri Dec 18 13:47:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA05381 for freebsd-mobile-outgoing; Fri, 18 Dec 1998 13:47:17 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from alink.net (br.alink.net [207.135.127.68]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA05375 for ; Fri, 18 Dec 1998 13:47:12 -0800 (PST) (envelope-from mab@zildjian.hq.alink.net) Received: from zildjian.hq.alink.net (lc.alink.net [207.135.127.87]) by alink.net (8.8.8/8.8.8) with ESMTP id NAA09217; Fri, 18 Dec 1998 13:47:02 -0800 (PST) Received: (from mab@localhost) by zildjian.hq.alink.net (8.8.8/8.8.8) id NAA16239; Fri, 18 Dec 1998 13:19:48 -0800 (PST) (envelope-from mab) From: Matt Braithwaite Reply-To: mab@alink.net X-Attribution: mab To: Mike Smith Cc: mobile@FreeBSD.ORG Subject: Re: APM can suspend right after resume without updating clock References: <199812180216.SAA00613@dingo.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 18 Dec 1998 13:19:48 -0800 In-Reply-To: Mike Smith's message of "Thu, 17 Dec 1998 18:16:58 -0800" Message-ID: <86btl1b11n.fsf@zildjian.hq.alink.net> Lines: 41 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "MS" == Mike Smith 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