From: Ray Lee <ray-lk@madrabbit.org>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Guarantee APM power status change notifications
Date: 01 Aug 2002 07:56:55 -0700 [thread overview]
Message-ID: <1028213816.1027.155.camel@orca> (raw)
In-Reply-To: <Pine.LNX.3.96.1020731160429.10522B-100000@gatekeeper.tmr.com>
[Trimmed the cc:]
On Wed, 2002-07-31 at 13:10, Bill Davidsen wrote:
> Actually there is one more case, where the BIOS unreliably tells you
> something has changed. I have an old Toshiba which I bought with Windows
> installed, and it always noticed pulling the plug and going line=>battery,
> but only sometimes noticed battery=>line. Of course this might be an o/s
> bug.
Well, that's just special. I wonder where the blame lies in that case.
> Can't test that any more, the battery failed and the transition is
> now line=>dead.
Heh.
> Anyway, if you are paranoid you could just ignore the "I knew that" cases
> and leave the workaround in place, unless that would generate other
> issues.
Hmm. I don't think that would cover everything. Taking your example
case, and assuming it's the BIOS being flaky, we'd have to just ignore
all transitions from the BIOS apm and just poll ourselves. Otherwise,
we'd have line->battery (signaled), battery->line (not signaled),
line->battery (signaled) and *then* we'd know to be paranoid. In the
meantime, we lost the second transition, which could have been hours
ago. The solution in that case would be to infrequently poll (say, twice
a minute) to verify what the BIOS told us. If it's out of sync, give it
a bit of a grace period, double-check, then take over the reins for
reporting.
The bottom line is that I didn't want to incur an extra set of BIOS
calls on systems that don't need it, on general principle. <Shrug> Heck,
maybe it's fast and the overhead is unnoticeable, but I don't know (ISTR
some low-latency issues when doing BIOS calls). Considering the APM
thread is only getting invoked once a second, it's seems that it would
be unnoticeable and zero risk, but hey, what do I know.
Anyway, a patch to do double-checking would be fairly straight-forward,
but without any reports of hardware out there that fails like that...
dunno. I'll work up a patch when I'm back from my road trip and see if
it's as clean.
Ray
next prev parent reply other threads:[~2002-08-01 14:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-26 23:42 [PATCH] fix APM notify of apmd for on-AC/on-battery transitions Ray Lee
2002-07-27 2:17 ` cort
2002-07-29 1:22 ` Ray Lee
2002-07-31 18:33 ` [PATCH] Guarantee APM power status change notifications Ray Lee
2002-07-31 20:10 ` Bill Davidsen
2002-08-01 14:56 ` Ray Lee [this message]
2002-08-01 18:52 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1028213816.1027.155.camel@orca \
--to=ray-lk@madrabbit.org \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox