Bug 100717
| Summary: | unsigned/signed int in apm | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | rgb |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | riel |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-30 15:41:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Well, here's the code in question, from arch/i386/kernel/apm.c
...
unsigned short bx;
unsigned short cx;
unsigned short dx;
int percentage = -1;
...
if ((smp_num_cpus == 1 || smp) &&
!(error = apm_get_power_status(&bx, &cx, &dx))) {
ac_line_status = (bx >> 8) & 0xff;
battery_status = bx & 0xff;
if ((cx & 0xff) != 0xff)
percentage = cx & 0xff;
...
It's clearly testing for one specific condition and leaving it set
to -1 in that case, which looks pretty intentional; it might have
to do with the APM spec, which I don't have a copy of.
Stephen Rothwell <sfr.org.au> is the upstream maintainer of APM.
Bugzilla doesn't really have a "forward upstream" feature. You could contact
Stephen yourself if you like.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/ |
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: This is a very simple one. On my laptop when it is truly 100% charged, /proc/apm shows the charge to be -1%. I note from elsewhere in the kernel bug list that this value also is reported when there is a broken BIOS (a toshiba, IIRC) so that the battery is always "100% full". This is a bit more than an annoyance -- a laptop can be set to shut down automatically if the charge is below e.g. 5%, and -1% is certainly less than that! It can actually cost you work and time if you disconnect the laptop at 100% charge only to be immediately shut down. Chances are really excellent that this is a trivial bug indeed. At a guess, the counter that determines battery charge is an unsigned int. At 100% full, it likely contains FFFFFFFF. This value is probably getting loaded into a signed int in the module that computes the % charge and presents it in /proc. The fact that in my laptop (set to NOT shut down right away if the charge falls below 5%) the value goes to 100% or 99% charge in the next proc update (going from -1% to 100%!) makes this almost a dead certainty. If this is the case, it should be very simple to fix. Even if it is not the case, it should be debugged, though -- /proc/apm should never show -1% under any circumstances, and even a hack fix that converts -1% results back into the 100% results that they truly represent before displaying is better than no fix at all. Version-Release number of selected component (if applicable): kernel-2.4.20-18.9 How reproducible: Sometimes Steps to Reproduce: 1.Charge laptop (Dell Inspiron 4000) to 100% 2.Disconnect from power 3.Sometimes (depending likely on exact state of counter) remaining charge is displayed as -1% in /proc/apm, with all derived values equally screwed, until charge drops by 1% or so. Actual Results: I get/got -1% remaining charge. Expected Results: I should have gotten 100% remaining charge. Additional info: This has happened for lots of kernel revisions; I just felt energetic enough today to report the bug. The bug should likely be forwarded upstream to the kernel list or apm person, if there is one, although it may be simple enough to send there with an accompanying patch. I doubt RH needs to layer a fix onto the existing kernel source, at any rate, unless it is necessary to use a hack (like the -1% -> 100% conditional).