Contribute
Register

Battery is always 100% charged when unplugged

Status
Not open for further replies.
Thanks for your reply.



Sorry, I tried to be as specific as possible w the version, I believe it was from the 4.1b1 thread. No matter though, I reinstalled using the 5.1b1 version from Tegezee's signature, using all of the same options described in my install (here).



At first (both with 4.1b1 and again w 5.1b1), when the AC is plugged in, percentage would display, and when on batt, "Not Charging" displayed with "plug" (full charge) logo would be displayed.

I tried the following fix (described earlier in this thread):
- Shut down computer
- Remove battery
- Hold down power button for 60s
- Reboot

Now I have the opposite problem (although much more usable this way).

- When on battery power, proper percentage displayed and seems to deplete appropriately with time
- When AC plugged in, "Not Charging" is displayed with 'plug' logo
- No change with sleep or reboot (same behavior always)

At least this way I'll get some indication of batt progress and warning before it dies.

Thanks again for your help!

Actually I see your other thread where you detail which DSDT (same as mine). That makes it easy...

Try the DSDT I attached. If you're curious to the code I added/removed look in the .DSL for '#if 1' (yes, iasl compiler understands C pre-processor directives) and you'll see... Basically, I'm disabling some of the special cases going on in the battery status code, and setting special bits in the status bits. If you run the debug version of my battery kext, we can actually see these special bits in the debug output and use the output to determine what path that method in the DSDT is taking... But besides that, I also wonder how the behavior is different with these changes to the DSDT...
 

Attachments

  • dsdt_battery_hack.zip
    136 KB · Views: 210
RehabMan, you are a Hacktintosh Saint!!! :D:thumbup::thumbup:

It works!! (In case you couldn't tell from the above).

There is only one small bug, if you were curious since it's in development:

- When I go from battery to AC, the "Not Charging (with plug logo)" flashes for about 1-2s before it resolves to the proper logo and percentage
- Going from AC to battery is normal expected behavior

But I can totally live with this!

Thank you so much for your help to me and the community!!
 
RehabMan, you are a Hacktintosh Saint!!! :D:thumbup::thumbup:

It works!! (In case you couldn't tell from the above).

There is only one small bug, if you were curious since it's in development:

- When I go from battery to AC, the "Not Charging (with plug logo)" flashes for about 1-2s before it resolves to the proper logo and percentage
- Going from AC to battery is normal expected behavior

But I can totally live with this!

Thank you so much for your help to me and the community!!

What fixed things for you here? The DSDT I hacked or my mods to glsy's battery manager I've been working on?? Or did you do both?

The "Not Charging" for a bit before going to "Calculating time Until Full" plug is normal. For some reason, when transitioning from "discharge" to "charge" there is a time when there is neither. This is something in the EC and since there are valid reasons for "not charging" (battery is hot, battery is charged or almost charged, battery is damaged), it is not like I can just assume that a transition from discharging to not-charging is a transition to charging...

At any rate, I'd be interested in knowing what fixed it for you, especially if it is (just) the DSDT... There's some petty slimy things I did in there, and it would be interesting to know which slimy thing is the one that makes it work.
 
What fixed things for you here? The DSDT I hacked or my mods to glsy's battery manager I've been working on?? Or did you do both?

The "Not Charging" for a bit before going to "Calculating time Until Full" plug is normal. For some reason, when transitioning from "discharge" to "charge" there is a time when there is neither. This is something in the EC and since there are valid reasons for "not charging" (battery is hot, battery is charged or almost charged, battery is damaged), it is not like I can just assume that a transition from discharging to not-charging is a transition to charging...

At any rate, I'd be interested in knowing what fixed it for you, especially if it is (just) the DSDT... There's some petty slimy things I did in there, and it would be interesting to know which slimy thing is the one that makes it work.

All i did was swap out my DSDT for yours (obviously renaming yours to DSDT.aml) in /Extra. On reboot, my battery was behaving normally. So I presume it was your DSDT edits then? I don't really understand how DSDT editing works. I started to look into trying to do this for myself (I didn't want to have to ask others to do my work for me) but quickly realized I don't have the background for it. Which is again why I am grateful for your help.

I was wondering if that might be normal, that makes sense. Then all the more congratulations. Whatever DSDT edits you made solved my issue. Hopefully they'll incorporate this in the next probook installer if other F23 users report similar issues. I doubt it's isolated to my system since my install is fairly generic and I assume it might be a BIOS related issue since that seems to be the only place where our systems differ?

Thanks again!
 
All i did was swap out my DSDT for yours (obviously renaming yours to DSDT.aml) in /Extra. On reboot, my battery was behaving normally. So I presume it was your DSDT edits then? I don't really understand how DSDT editing works. I started to look into trying to do this for myself (I didn't want to have to ask others to do my work for me) but quickly realized I don't have the background for it. Which is again why I am grateful for your help.

I was wondering if that might be normal, that makes sense. Then all the more congratulations. Whatever DSDT edits you made solved my issue. Hopefully they'll incorporate this in the next probook installer if other F23 users report similar issues. I doubt it's isolated to my system since my install is fairly generic and I assume it might be a BIOS related issue since that seems to be the only place where our systems differ?

Thanks again!

OK, now we are getting it narrowed down a bit. What would be great is if you could load the debug version of AppleSmartBatteryManager.kext, available here: http://www.tonymacx86.com/hp-proboo...-fix-boot-without-batteries-6.html#post436372

- Install it using Kext Wizard, then restart your laptop.
- remove the AC adapter then, let your battery run down to 90%
- then plug in
- after letting it run for a couple of minutes, start Console.app
- search in the box for AppleSmartBattery
- select as much of the output that you can, zip it up, and post it.

I'd like to see exactly which part of my DSDT hack fixed your issue, and I think the output from the debug kext will tell me.

Here's my changes to the DSDT code, with some explanation:

Code:
// Method BTST is called to return battery status
//       index 0: bitfield showing charging or not, bit 0 is discharging, bit 1 is charging, bit 2 is "error" bit 
//       index 1: present rate of charge/discharge
//       index 2: battery remaining capacity
//       index 3: battery present voltage
                    Method (BTST, 2, Serialized)
                    {
// Arg0 is the battery # we wish to get status of
                        ShiftLeft (One, Arg0, Local7)
                        BTDR (One)
                        If (LEqual (BSTA (Local7), 0x0F))
                        {
// this is some error condition
                            Store (Package (0x04)
                                {
                                    Zero, 
                                    0xFFFFFFFF, 
                                    0xFFFFFFFF, 
                                    0xFFFFFFFF
                                }, Index (NBST, Arg0))
                            Return (0xFF)
                        }

// not sure what this is accomplishing, but it isn't related to our issue...
//  some sort of lock while the code below runs 
                        Acquire (BTMX, 0xFFFF)
                        If (Arg1)
                        {
                            Store (0xFF, NGBT)
                        }
                        Store (NGBT, Local0)
                        Release (BTMX)

// another error condition, don't think this is happening
// I think it is a check to see that there isn't a request for battery status 
//        on a battery that isn't even installed.
//
// it is kind of sketchy that in this case they return prematurely before undoing 
// whatever lock they just did above...
                        If (LEqual (And (Local0, Local7), Zero))
                        {
                            Return (Zero)
                        }

// now we begin on the guts, grab a mutex for the EC
                        Acquire (ECMX, 0xFFFF)
                        If (ECRG)
                        {
// grab most of the raw data we need for this function from the EC
                            Store (Arg0, BSEL)
// charging/discharging status into Local0
                            Store (BST, Local0)
// present rate into Local3
                            Store (B1B2 (BPR0, BPR1), Local3)
// store current capacity and present voltage right into the result (index 2 and 3)
                            Store (B1B2 (BRC0, BRC1), Index (DerefOf (Index (NBST, Arg0)), 0x02))
                            Store (B1B2 (BPV0, BPV1), Index (DerefOf (Index (NBST, Arg0)), 0x03))
                        }
                        Release (ECMX)

// Method call to GACS has to do with getting AC status
//   it does some stuff then returns ACST (AC "status")
//   checking if AC status == 1
// This whole section is some kind of "sanity check"
                        If (LEqual (GACS (), One))
                        {
#if 1
// I added this here because I want to know if bit 0 of Local0 would normally be cleared
//   status will have bit 8 set if we follow this path   
// And note, the code below (original) is not compiled in.
                            if (And (Local0, 1)) { Store (Or (Local0, 0x100), Local0) }
#else								
// logic here is something like ACST is 1, so can't be discharging (discharging is bit 0 of Local0)
//    this makes sure bit0 is cleared if AC status is 1
                            And (0xFFFFFFFFFFFFFFFE, Local0, Local0)                            
#endif                            
                        }
                        Else
                        {
// similar thing going on here as above, but with charging bit...
//       ie. not on AC power, so better not be charging...
// I set bit 9 of Local0 (status) just to see if this is happening normally
#if 1                        
                            if (And (Local0, 2)) { Store (Or (Local0, 0x200), Local0) }
#else                        		
                            And (0xFFFFFFFFFFFFFFFD, Local0, Local0)
#endif                            
                        }

                        If (And (Local0, One))
                        {
                            Acquire (BTMX, 0xFFFF)
                            Store (Local7, NDCB)
                            Release (BTMX)
                        }

#if 1
// I put this in just because I wanted to see if the DSDT code I changed here is getting run.
// (way to make sure the DSDT I sent you gets copied to right place, and way to make sure, I'm 
// right about this being the code called when getting ACPI battery status.
// Setting bit 4 of status (remember, only bits 0, 1, and 2 are used "officially")
                        Store (Or (Local0, 0x10), Local0)
#endif						
// checking if "discharging"... special case code follows
                        If (And (Local0, One))
                        {
// this is kind of interesting, I guess HP can't trust the data coming from their controller,
// so they sanity check it here.  must be between 0x190 and 0x1964 or...
// Local3 is present (discharge) rate here
                            If (LOr (LLess (Local3, 0x0190), LGreater (Local3, 0x1964)))
                            {
// not in right range, so grab data that they stored here last time
                                Store (DerefOf (Index (DerefOf (Index (NBST, Arg0)), One)), 
                                    Local5)
// then sanity check again,
                                If (LOr (LLess (Local5, 0x0190), LGreater (Local5, 0x1964)))
                                {
// and... oh crap, if still not in range, then store some arbitrary value for present charge
                                    Store (0x0D7A, Local3)
#if 1
// and I wanted to know if this is happening so setting bit 5
                                    Store (Or (Local0, 0x20), Local0)
#endif                                    
                                }
                                Else
                                {
// this is the case where they use the last value that was within range as that is in Local5
                                    Store (Local5, Local3)
#if 1
// and I also wanted to know if this is happening, so setting bit 6
                                    Store (Or (Local0, 0x40), Local0)
#endif                                    
                                }
                            }
                        }
                        Else
                        {
// this is the case of not discharging
// here they are looking at whether there is any charging status reported and if not...
                            If (LEqual (And (Local0, 0x02), Zero))
                            {
#if 1
// but... I do want to know when the code might have done this... so set bit 7
                                Store (Or (Local0, 0x80), Local0)
#else
// if no charging status reported, then better report "present charge" at 0
// I didn't want this to happen because I want to see what they report as present charge in the case
//  of no charge or discharge state
                                Store (Zero, Local3)
#endif
                            }
                        }

// finally, it stores the results calculated by logic above...
                        Store (Local0, Index (DerefOf (Index (NBST, Arg0)), Zero))
                        Store (Local3, Index (DerefOf (Index (NBST, Arg0)), One))

// more manipulation of the BTMX/NGBT (must be some kind of "lock")
                        Acquire (BTMX, 0xFFFF)
                        And (NGBT, Not (Local7), NGBT)
                        Release (BTMX)
                        Return (Zero)
                    }

So, if you'd run the debug version of the battery kext for me (referenced above), I'd be able to figure out which modification of this DSDT code path was significant...

BTW, the lines showing the various status bits will be lines like:
Code:
...
9/2/12 11:09:10.000 PM kernel[0]: AppleSmartBattery::setBatteryBST: currentStatus    = 0x90
...
 
What would be great is if you could load the debug version of AppleSmartBatteryManager.kext, available here: Battery Manager with Fix for Boot without Batteries

- Install it using Kext Wizard, then restart your laptop.
- remove the AC adapter then, let your battery run down to 90%
- then plug in
- after letting it run for a couple of minutes, start Console.app
- search in the box for AppleSmartBattery
- select as much of the output that you can, zip it up, and post it.

I'd like to see exactly which part of my DSDT hack fixed your issue, and I think the output from the debug kext will tell me.

Here you go! Hopefully that helps your development and some others in the future.

View attachment AppleSmartBattery__RehabMan_Output.zip

Thanks again RehabMan!
 
Here you go! Hopefully that helps your development and some others in the future.

View attachment 30387

Thanks again RehabMan!

Nice. The first couple of polls look like your battery is charged and your AC is plugged in and properly detected.
Code:
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery::setBatteryBST: currentStatus    = [b]0x90[/b]
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x1a6
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x1172
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x30e1
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery::setBatteryBST: fAverageRate = 0x36a
12-09-03 3:29:25.000 AM	kernel	AppleSmartBattery: Battery is charged.

Status is 0x90 (binary 10010000) to indicate "no charge/discharge" (bit 0 and 1 are zero). Bit 4 just tells us my custom DSDT code is running (it will always be set). And bit 7 set indicates it fell into the code that would normally zero out present rate. Because of my changes it is not clearing it out so fCurrentRate shows something. Whether that is correct or not depends on what you know about the state of your battery at that particular moment. Was it in need of a charge at that point? I would guess no, as the fCurrentCapacity is relatively high indicating a full charge.

Later on we see a poll that must have executed after you unplugged.
Code:
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery::setBatteryBST: currentStatus    = 0x111
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x520
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0x1172
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x3087
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery::setBatteryBST: fAverageRate = 0x445
12-09-03 3:29:26.000 AM	kernel	AppleSmartBattery: Battery is discharging.
Note that currentStatus now reads 0x111 (binary 100010001). Bit 8 (0x1-- part) indicates the code didn't properly detect AC disconnect and it would have cleared bit 0 (0x--1) the bit that indicates discharge -- it "thinks" AC is connected so is clearing out the discharge bit coming from the EC). If you didn't have the changes to the DSDT, the battery manager would think you laptop was plugged in and 100% charged (because that's what it assumes if no discharge or charge is in effect). I don't think it is a particularly good assumption and will probably try to fix it in the battery kext. Because of the changes, we keep the discharge bit coming from the EC and the kext can properly report "battery is discharging."

Bit 4 tells us our DSDT code is running (always set). And finally bit 0 is showing true discharge status from the EC.

Note that this is exactly the opposite of your latest results after resetting your laptop. Obviously, it has reverted to it's old behavior.

Later you can see where you plugged the AC adapter back in.
Code:
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: fPowerUnit       = 0x1
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: currentStatus    = 0x90
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x0
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0xf64
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x2ec0
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x8bb
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery::setBatteryBST: fAverageRate = 0x725
12-09-03 3:52:59.000 AM	kernel	AppleSmartBattery: Battery is charged.

That is the "transition" poll from discharge to charge. Sometimes there is two of these. It just depends on the length of the transition and the specifics of the timing of the polls. This is where the battery kext "thinks" the battery is 100% charged, and will temporarily show that. My latest version changes this behavior and shows just "Not Charging" and the current percentage instead of jumping to 100%. In this case you can see that the status is 0x90 (binary 10010000) again like it was at the beginning when you had a full charge. But that only lasts so long, as the next poll is like this:

Code:
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: currentStatus    = 0x12
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentRate     = 0x0
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0xf64
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x2ee8
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: adjusted fCurrentRate = 0x8bb
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery::setBatteryBST: fAverageRate = 0x8bb
12-09-03 3:53:02.000 AM	kernel	AppleSmartBattery: Battery is charging.

Status is now 0x12 (binary 00010010). Bit 4 always set, as usual. Bit 1 indicates "charging." No other bits set, so we would have this indication even without the DSDT changes.

So now, it correctly detects that the battery is charging, but it shows present rate at zero. Fortunately, a few polls later, present rate finally fills in. I guess it may take the battery hardware a while to detect the present rate... That's fine it just takes a little longer to "Calculate time Until Full"

Code:
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery::setBatteryBST: currentStatus    = 0x12
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentRate     = 0xbf9
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentCapacity = 0xf96
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery::setBatteryBST: fCurrentVoltage  = 0x30d3
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery::setBatteryBST: fAverageRate = 0xa5a
12-09-03 3:54:04.000 AM	kernel	AppleSmartBattery: Battery is charging.

So, thanks for that information. It is great to see at least one side of this problem. It would have been nice to see the other scenario, where you are getting correct discharge indications, but not correct charge indications...

But I wonder why this happens with certain ProBooks. I wonder if it is something to do with using an F20 DSDT on an F23 BIOS? Could you produce a clean DSDT dump for me for BIOS F23? To do so:

- run Ubuntu 12.04 from Live CD/USB (don't install, just run it)
- open Terminal with Ctrl+Alt+T
- run following commands at Terminal:
sudo apt-get install acpidump
sudo acpidump -b -t DSDT -o dsdt.aml
- now copy dsdt.aml somewhere that you can upload it here, or connect to your wireless and run Firefox right from Ubuntu and upload it from there

It would be interesting to 1) see a clean DSDT for F23 ... I could compare it to F20 to see what's different, and 2) Patch F23 to create one custom for F23
 
Sorry, I have to be quick, just runnning out...

- run following commands at Terminal:
sudo apt-get install acpidump

Returns:
Code:
Reading package lists... Done
Building dependancy tree
Reading state information... Done
E: Unable to locate package acpidump

LAN connection is good.
 
Sorry, I have to be quick, just runnning out...



Returns:
Code:
Reading package lists... Done
Building dependancy tree
Reading state information... Done
E: Unable to locate package acpidump

LAN connection is good.

Sorry about that... there are few more steps (of course, this is Linux, right...)
You need to add universe to your software sources, then do apt-get update first.

Before Terminal, go to Ubuntu Software Center (it is the shopping bag icon with stuff exploding out of it!!)
Select Edit.Software Sources... from the menu.
Check the "Community maintained free... (universe)" item.
Close that dialog.
Now go into Terminal and...
Code:
sudo apt-get update
sudo apt-get install acpidump
sudo acpidump -b -t DSDT -o dsdt.aml
 
It would have been nice to see the other scenario, where you are getting correct discharge indications, but not correct charge indications...

I think I could make that happen by installing the old Probook default (before your fix). After initial install, before doing the 'power-button reset' thing, it has that behaviour. Presumably, if I had the debug kext installed, I could get the output you want?

Before Terminal, go to Ubuntu Software Center (it is the shopping bag icon with stuff exploding out of it!!)
Select Edit.Software Sources... from the menu.
Check the "Community maintained free... (universe)" item.
Close that dialog.
Now go into Terminal and...

I'm not sure why, but that didn't change anything, I got the same result (not found), even with the new repo loaded. In any event, I just found a .deb for 12.04 and installed it through software centre.

View attachment Probook4530sF23_dsdt.aml.tar.gz
(Note to new users, this is a RAW dsdt from Linux, DO NOT INSTALL IT on your system)

Hope that helps. Thanks again for your work on this.
 
Status
Not open for further replies.
Back
Top