Contribute
Register

HP Pavilion Dm4-1265Dx Battery reporting wrong state

Status
Not open for further replies.
When discharging, it may be normal for the present rate to be zero for a very short time (few seconds).
After that, it should accurately reflect the discharge rate.
In my laptop, it always stays at 0x0 even when discharging, no matter how long.

I also noticed that _BST returns incorrect value, when I'm booting up, _BST package shows that I'm charging, but I am not charging since the time I opened the computer: { "BAT0._BST return", { 0x1, 0x0, 0x471, 0x2968,},}
 
In my laptop, it always stays at 0x0 even when discharging, no matter how long.

You will need to debug your DSDT _BST method.
ACPIDebug is handy for that.

I also noticed that _BST returns incorrect value, when I'm booting up, _BST package shows that I'm charging, but I am not charging since the time I opened the computer: { "BAT0._BST return", { 0x1, 0x0, 0x471, 0x2968,},}

Another bug for you to look into.
Perhaps your ACPI/patched is not in sync with native, or ACPI/patched content is not patched correctly.

You might want to look into the patch for "HP DV6 3165sf" which replaces UPBS completely.
 
Another bug for you to look into.
Perhaps your ACPI/patched is not in sync with native, or ACPI/patched content is not patched correctly.

You might want to look into the patch for "HP DV6 3165sf" which replaces UPBS completely.
I don't have UPBS method on my laptop tho....
 
Also, I noticed every time I discharge it (however, this is not the case when I boot up the laptop with no charger), both ACPIDebug, Debug ACPIBatteryManager literally polls every seconds. Should this be a thing?
 
I don't have UPBS method on my laptop tho....

The UPBS is a helper for _BST. Yours might be called something else, or the code may be embedded directly in _BST itself.
 
Also, I noticed every time I discharge it (however, this is not the case when I boot up the laptop with no charger), both ACPIDebug, Debug ACPIBatteryManager literally polls every seconds. Should this be a thing?

ACPIDebug does not do any battery related polling.
But your debug output will write to kernel log anytime the instrumented methods are called.
ACPIBatteryManager.kext polls once every second when it is expecting a transition.
After the expected transition is noticed, ACPIBatteryManager polls every 30 seconds.
The logic for resetting the timer is in pollBatteryState:
Code:
    if (!fPollingOverridden)
    {
        // at startup, polling is quick for slow to respond ACPI implementations
        if (fStartupFastPoll)
        {
            DebugLog("fStartupFastPoll=%d\n", fStartupFastPoll);
            --fStartupFastPoll;
            if (!fStartupFastPoll)
                fPollingInterval = kDefaultPollInterval;
        }

        DebugLog("fRealAC=%d, fACConnected=%d\n", fRealAC, fACConnected);
        if (-1 == fRealAC || fRealAC == fACConnected)
        {
            // Restart timer with standard polling interval
            fPollTimer->setTimeoutMS(milliSecPollingTable[fPollingInterval]);
        }
        else
        {
            // Restart timer with quick polling interval
            fPollTimer->setTimeoutMS(milliSecPollingTable[kQuickPollInterval]);
        }
    }
    else
    {
        // restart timer with debug value
        fPollTimer->setTimeoutMS(1000 * fPollingInterval);
    }

The milliSecPollingTable is defined as:
Code:
static uint32_t milliSecPollingTable[2] =
{ 
30000,    // 0 == Regular 30 second polling
1000      // 1 == Quick 1 second polling
};
 
ACPIBatteryManager.kext polls once every second when it is expecting a transition.
I guess because it is expecting the transition to happen (which it never did), it keeps polling and polling for every second until the power runs out.

So I guess the problem is at the transition state between AC and battery (since AC works fine).
 
The UPBS is a helper for _BST. Yours might be called something else, or the code may be embedded directly in _BST itself.
How do I identify it (the helper)?
 
It may not use one.
You will need to read your _BST code.
Code:
"BAT0._BST enter"
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: setBatteryBST: acpibat_bst size = 4
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fPowerUnit       = 0x1
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: currentStatus    = 0x2
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fCurrentRate     = 0
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fCurrentCapacity = 2111
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fCurrentVoltage  = 12535
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fAverageRate = 0
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: Battery is charging.
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: rebuildLegacyIOBatteryInfo called
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIBatteryManager: fRealAC=1, fACConnected=1
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIDebug: { "BAT0._BST return", { 0x2, 0x0, 0x83f, 0x30f7, }, }
Dec 23 08:03:21 Baddless-MBP kernel[0]: ACPIDebug: "BAT0._BST exit"
Like this one when it is charging at 67%, It means there's no helper for BST?
(That's all of the log that BST returns).
 
Status
Not open for further replies.
Back
Top