On 1 Aug 2002, Ray Lee wrote:
> [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.
Okay, I said "other issues" and that certainly is one.
> 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.
Bear in mind that I was being pedantic to mention the other case, I would
think that if this is worth doing at all (is it?) just an option to ignore
the BIOS might be fine:
modprobe apm my_bios_sucks=sad_but_true
or some such. If anyone was convinced there was such an issue they could
do it. Again, it could have been the o/s just losing the int when running
slow on battery. M$ losing ints? Nah, can't happen ;-)
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:16 EST