From owner-freebsd-mobile Thu Dec 17 18:19:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25804 for freebsd-mobile-outgoing; Thu, 17 Dec 1998 18:19:12 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25797 for ; Thu, 17 Dec 1998 18:19:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA00613; Thu, 17 Dec 1998 18:16:58 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812180216.SAA00613@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 "17 Dec 1998 13:28:34 PST." <86empyjw59.fsf@zildjian.hq.alink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Dec 1998 18:16:58 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > when i powered up today, my machine (nec versa lx) suspended > instantly. i connected AC power, and powered up again. dmesg showed > only this: > > \^G\^G * * * BATTERY IS LOW * * * \^G\^G<5>resumed from suspended mode > (slept 00:00:41) > > but the first time i powered it up, it had been asleep for over eight > hours. unsurprisingly, the clock was off by that amount of time. > looking at apm.c (2.2.8-STABLE), it's easy to see how this could > happen: the low power event inevitably suspends the machine right > away: > > OPMEV_DEBUGMESSAGE(PMEV_BATTERYLOW); > apm_battery_low(); > apm_suspend(); > break; > > my guess is that for some reason, the APM code got hold of the low > battery event before the resume event. unfortunately, i don't know > how best to fix this. is it easy to schedule the suspend a little bit > into the future, to catch other events? Not really easily, no. I'm not sure that it'd actually be terribly useful to do that either, apart from the improved sleep time message. > would it be easy to update > the clock before suspending? Ah, I think I see what you mean; the loss of the resume message means that the clock hasn't been updated. Probably a better approach would simply be to reload the system clock from the RTC. > could suspending on low battery be left > up to user code? What benefits would that bring? The events still need to be fetched in the kernel, and most event handling is pretty trivial... -- \\ 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