Bug 54241

Summary: Wrong battery capacity values on HP Folio 13-2000
Product: ACPI Reporter: Stefan Nagy (stefan.nagy)
Component: Power-BatteryAssignee: Lan Tianyu (tianyu.lan)
Status: CLOSED INVALID    
Severity: normal CC: tianyu.lan
Priority: P1    
Hardware: All   
OS: Linux   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701050
Kernel Version: 3.7.9 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg log (kernel 3.7.9)
output of lspci -vvnn
output of dmidecode
output of acpidump
debug.patch

Description Stefan Nagy 2013-02-22 17:10:42 UTC
Created attachment 93831 [details]
dmesg log (kernel 3.7.9)

While my BIOS/UEFI reports a battery charge capacity of 92% for my notebook-
battery, the kernel still reports a charge capacity of 100%.

I checked the situation in Windows 7 over the last few days and I don't see 
the problem there. I can use the 'HP Support Assistant' in Windows to 
check the battery capacity and status – it seems to be the same tool as 
in the 'HP UEFI Support Environment'. The value 'Current' (in mAh) 
accords to the values (in percentage of 'Full Charge Capacity') reported 
by Windows. This is why I don't think that this is a firmware bug.

I'll add the information provided by UEFI (1.) and the kernel (2.).


(1.) Information provided by the HP UEFI Support Environment:
Charge Capacity: 92%
Warranty Type: 1 year
Cycle Count: 187
Manufacturer: 13-17
Battery Age: 391 days
Serial Number: 01317 01/24/2012
Temperature: 36 °C
Design Capacity: 5400 mAh
Full Charge Capacity: 5020 mAh
Remaining Capacity: 2499 mAh
Current: 1797 mA
Battery Status: OK(1)
FAILURE ID: OK
Terminal Voltage: 11143 mV
Design Voltage: 11100 mV
Cell Voltage 1: 3710 mV
Cell Voltage 2: 3735 mV
Cell Voltage 3: 3700 mV
Cell Voltage 4: 0 mV
Status: 00C0
AC Power: No
CT Number: 6CLFH02BJ2E08M

(2.) Information provided by the kernel:
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=11854000
POWER_SUPPLY_POWER_NOW=11877000
POWER_SUPPLY_ENERGY_FULL_DESIGN=59940000
POWER_SUPPLY_ENERGY_FULL=59940000
POWER_SUPPLY_ENERGY_NOW=49750000
POWER_SUPPLY_CAPACITY=82
POWER_SUPPLY_MODEL_NAME=Venturi
POWER_SUPPLY_MANUFACTURER=13-17
POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012
Comment 1 Stefan Nagy 2013-02-22 17:12:24 UTC
Created attachment 93841 [details]
output of lspci -vvnn
Comment 2 Stefan Nagy 2013-02-22 17:13:17 UTC
Created attachment 93851 [details]
output of dmidecode
Comment 3 Stefan Nagy 2013-02-22 17:14:19 UTC
Created attachment 93861 [details]
output of acpidump
Comment 4 Lan Tianyu 2013-02-28 14:09:26 UTC
(In reply to comment #0)
> POWER_SUPPLY_ENERGY_FULL=59940000
> POWER_SUPPLY_ENERGY_NOW=49750000
> POWER_SUPPLY_CAPACITY=82
> POWER_SUPPLY_MODEL_NAME=Venturi
> POWER_SUPPLY_MANUFACTURER=13-17
> POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012

The output show the capacity 82% rather than 100%. Did  I miss something?
Comment 5 Stefan Nagy 2013-02-28 14:48:02 UTC
POWER_SUPPLY_CAPACITY seems to show the current charging level, not the capacity of the battery. Right now I have POWER_SUPPLY_CAPACITY=24, which corresponds to 'battery percentage' in the output of 'upower --dump' and the value, the GNOME battery status applet gives me.

The relevant values are POWER_SUPPLY_ENERGY_FULL_DESIGN and POWER_SUPPLY_ENERGY_FULL, which are the same in the output I posted above – which means the capacity of the battery should be 100% (like it would be a brand new battery).

Apart from the fact that the battery is one year old and thus can't have a capacity of 100% the HP UEFI Support Environment tells me that 'Charge Capacity' is 92%. The relevant values here are 'Design Capacity' (5400 mAh) and 'Full Charge Capacity' (5020 mAh): 5020 / 5400 = 0,92962963.


So this bug report is about the following values:

Design Capacity: 5400 mAh
Full Charge Capacity: 5020 mAh

and

POWER_SUPPLY_ENERGY_FULL_DESIGN=59940000
POWER_SUPPLY_ENERGY_FULL=59940000.
Comment 6 Lan Tianyu 2013-03-21 13:07:56 UTC
Created attachment 95911 [details]
debug.patch

Please try this patch. There is a quirk to make ENERGY_FULL equal to 
ENERGY_FULL_DESIGN when the datas from bios are uncorrect. This patch is to comment the quirk.
Comment 7 Stefan Nagy 2013-03-21 21:11:03 UTC
After applying the patch provided in comment #6, the kernel still reports the same values:

POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=12096000
POWER_SUPPLY_POWER_NOW=8635000
POWER_SUPPLY_ENERGY_FULL_DESIGN=59940000
POWER_SUPPLY_ENERGY_FULL=59940000
POWER_SUPPLY_ENERGY_NOW=53946000
POWER_SUPPLY_CAPACITY=90
POWER_SUPPLY_MODEL_NAME=Venturi
POWER_SUPPLY_MANUFACTURER=13-17
POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012
Comment 8 Lan Tianyu 2013-03-22 03:00:49 UTC
Read dsdt table from bios, all ENERGY_FULL_DESIGN and ENERGY_FULL are from BIF method. Their value are in same process.

BIF return package definition.
ACPI 5.0 spec page 497
Package {
	Power Unit // Integer (DWORD)
	Design Capacity // Integer (DWORD) 
	Last Full Charge Capacity // Integer (DWORD)
	Battery Technology // Integer (DWORD)
	Design Voltage // Integer (DWORD)
	Design Capacity of Warning // Integer (DWORD)
	Design Capacity of Low // Integer (DWORD)
	Battery Capacity Granularity 1 // Integer (DWORD)
	Battery Capacity Granularity 2 // Integer (DWORD)
	Model Number // String (ASCIIZ)
	Serial Number // String (ASCIIZ)
	Battery Type // String (ASCIIZ)
	OEM Information // String (ASCIIZ)
}

Method (_BIF, 0, NotSerialized)
{
    Name (STAT, Package (0x0D)
    {
        One,
        0x1770,<= initial value of ENERGY_FULL_DESIGN
        0x1770,<= initial value of ENERGY_FULL
        One,
        0x2A30,
        0x0258,
        0xB4,
        0x0108,
        0x0EC4,
        "PABAS0241231",
        "41167",
        "Li-Ion",
        "Hewlett-Packard"
    })
    Store (^^EC0.BAM0, Index (STAT, Zero))
    Store (^^EC0.GBMN (), Index (STAT, 0x09))
    Store (^^EC0.GUBS (), Index (STAT, 0x0A))
    Store (^^EC0.GUBT (), Index (STAT, 0x0B))
    Store (^^EC0.GUBI (), Index (STAT, 0x0C))
    If (ECOK ())
    {
        Store (^^EC0.BDN0, Local0)
        Store (Local0, BMDL)
        Store (Multiply (^^EC0.BDC0, 0x0A), Index (STAT, One))<= FULL_DESIGN
        Sleep (0x14)
        Store (Multiply (^^EC0.BDC0, 0x0A), Local2)
        Store (Local2, Index (STAT, 0x02))<= FULL
        Sleep (0x14)
        If (Local2)
        {
            Divide (Local2, 0x64, Local0, Local1)
            Multiply (Local1, 0x05, Local1)
            Store (Local1, Index (STAT, 0x05))
            Divide (Local2, 0x64, Local0, Local1)
            Multiply (Local1, 0x03, Local1)
            Store (Local1, Index (STAT, 0x06))
        }

        Store (^^EC0.BDV0, Index (STAT, 0x04))
        Sleep (0x14)
    }

    Return (STAT)
}

From the bios code, the values for ENERGY_FULL_DESIGN and ENERGY_FULL are always same. This is a bios bug.
Comment 9 Stefan Nagy 2013-03-22 14:12:31 UTC
Thanks, I think I can confirm that this is a BIOS bug: I had access to another HP Folio 13-1200 running Windows 7 today and I checked the battery information in Windows with 'powercfg -energy'. The reported values for 'Design capacity' (=ENERGY_FULL_DESIGN) and 'Last full charge' (=ENERGY_FULL) are the same: 59940.

The correct values for this notebook, which are reported by the 'HP UEFI Support Environment' as well as the Windows program 'HP Support Assistant', are: 'Design Capacity' (=ENERGY_FULL_DESIGN) 5400 mAh and 'Full Charge Capacity' (=ENERGY_FULL) 5075 mAh. Thus, the real charge capacity is 94%.


For more testing I downloaded a freeware tool to access more battery info. The tool provided just the same information as the linux kernel on my notebook. Now, the strange thing is, that the percentage (remaining CAPACITY) reported by Windows 7 (as well as the freeware tool) and the 'HP Support Assistant' are all the same – even if the ENERGY_FULL values are different.

How's that possible? Not only the ENERGY_FULL values, but *also the ENERGY_NOW values* differ, even though the reported values for VOLTAGE_NOW (terminal voltage) are the same. For example right now I get the following values:

1. With 'HP Support Assistant':
ENERGY_FULL_DESIGN = 5400 mAh
ENERGY_FULL        = 5036 mAh
ENERGY_NOW         = 4495 mAh
CAPACITY           = 89% (makes sense: 4495 / 5036 = 0,89257)
VOLTRAGE_NOW       = 11.996 mV

2. With the freeware tool under Windows 7:
ENERGY_FULL_DESIGN = 59.940 mWh
ENERGY_FULL        = 59.940 mWh
ENERGY_NOW         = 53.346 mWh
CAPACITY           = 89% (makes sense: 53.346 / 59.940 = 0,88999)
VOLTRAGE_NOW       = 11.996 mV.


I don't really get it. However, this really seems to be just another BIOS bug…
Comment 10 Lan Tianyu 2013-03-22 14:38:40 UTC
Look like you have encountered some other bios bugs.
Could you share your info?  :)
Close this bug first.
Comment 11 Stefan Nagy 2013-03-22 18:36:39 UTC
You were the one who told me bug #52111 would be a BIOS bug ;) I'd guess it was a symptom of this bug here.

There are several power management issues (symptoms?) on this notebook and I'm not sure if and how they are connected. Take for example bug #54621: I don't know how that bug could have anything to do with this issue, since it affects the battery as well as the ac adapter (the kernel doesn't produce uevents for any of those two devices) while here only the battery is affected.

I can think of easy workarounds for bug #52111 and this one: for example change org.gnome.settings-daemon.plugins.power use-time-for-policy to false and set percentage-critical to 7 and percentage-action to 5. However, this doesn't help as long as bug #54621 isn't fixed since upower will never update the status of the ac adapter. And I really can't think of an easy workaround for this. Maybe I could ask the upower developers to force status updates not only for the battery but also for the ac adapter…

At least I know that I shouldn't have any hope that the vendor will fix the broken BIOS. HP support told me, that as long as I don't touch the Windows power setting's defaults (send to hibernate at 5% battery capacity) I'd be just fine and that the notebook 'works as designed'.