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
-
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/