From owner-freebsd-mobile Fri Dec 18 14:15:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08720 for freebsd-mobile-outgoing; Fri, 18 Dec 1998 14:15:09 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles251.castles.com [208.214.165.251]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08709 for ; Fri, 18 Dec 1998 14:15:06 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id OAA03014; Fri, 18 Dec 1998 14:12:42 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812182212.OAA03014@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mab@alink.net cc: mobile@FreeBSD.ORG Subject: Re: APM can suspend right after resume without updating clock In-reply-to: Your message of "18 Dec 1998 13:19:48 PST." <86btl1b11n.fsf@zildjian.hq.alink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Dec 1998 14:12:41 -0800 From: Mike Smith 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. :-) No kidding. > 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. The code in -current is more complex, but either way it looks as though all this is doing is processing the resume event from after the low-battery powerdown, ie. when the system was resumed the APM code returned the low-battery event *before* the resume event. This is really a bug in your BIOS, but we can probably work around it by always doing the resume processing when the suspend call returns. > >> 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. Even if you selected on it the kernel would still have to poll the APM BIOS - that's just how it works. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message