Date: Fri, 18 Dec 1998 14:12:41 -0800 From: Mike Smith <mike@smith.net.au> To: mab@alink.net Cc: mobile@FreeBSD.ORG Subject: Re: APM can suspend right after resume without updating clock Message-ID: <199812182212.OAA03014@dingo.cdrom.com> In-Reply-To: Your message of "18 Dec 1998 13:19:48 PST." <86btl1b11n.fsf@zildjian.hq.alink.net>
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. :-) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812182212.OAA03014>