Bug 100717 - unsigned/signed int in apm
Summary: unsigned/signed int in apm
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-24 15:23 UTC by rgb
Modified: 2007-04-18 16:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:41:20 UTC
Embargoed:


Attachments (Terms of Use)

Description rgb 2003-07-24 15:23:38 UTC
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).

Comment 1 Michael K. Johnson 2003-08-08 00:04:16 UTC
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.

Comment 2 Bugzilla owner 2004-09-30 15:41:20 UTC
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/



Note You need to log in before you can comment on or make changes to this bug.