Battery Manager with Fix for Boot without Batteries

[lisai9093]

You need to debug your DSDT battery methods. Use ACPIDebug. Refer to the ACPI spec for information on _BST.

Ok thanks~ will try later time

 

[TimeWalker]

Hey there, finally catching up with things ... installing your latest releases and getting around with setting them up.
Stumbled upon a bug when comprising the serial number for system profile?

06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: setBatteryBIF: acpibat_bif size = 13
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fPowerUnit       = 0x1
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDesignCapacityRaw  = 6200
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fMaxCapacityRaw     = 4522
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fBatteryTech     = 0x0
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDesignVoltage   = 10800
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fCapacityWarningRaw = 452
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fLowWarningRaw      = 0
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDeviceName      = 'Dell'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fSerialNumber    = '1950'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fType            = 'LION'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fManufacturer    = 'SANYO'

IOService:/AppleACPIPlatformExpert/BAT0/AppleSmartBatteryManager/AppleSmartBattery

On this unit, ACPI only utilizes BIF (extended and extra flags are set to n in config). The serial number and device name are correctly reported here whens setting BIF and so is the manufacturer, however when you look at what has been result of constructAppleSerialNumber - things don't seem quite right. When calling setSerialNumber from setBatteryBIF, number is present as you can see from debug above. As FirmwareSerialNumber is presented as 0x1950 in IOReg, _SerialNumberSym can't be empty and therefore should return a valid numeric value to the calling method?

It used to show up OK with 1.55 I was using previously...

 

[RehabMan]

Hey there, finally catching up with things ... installing your latest releases and getting around with setting them up.
Stumbled upon a bug when comprising the serial number for system profile?

06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: setBatteryBIF: acpibat_bif size = 13
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fPowerUnit       = 0x1
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDesignCapacityRaw  = 6200
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fMaxCapacityRaw     = 4522
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fBatteryTech     = 0x0
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDesignVoltage   = 10800
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fCapacityWarningRaw = 452
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fLowWarningRaw      = 0
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fDeviceName      = 'Dell'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fSerialNumber    = '1950'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fType            = 'LION'
06.25.16 9:29:38.000 PM kernel[0]: ACPIBatteryManager: fManufacturer    = 'SANYO'

IOService:/AppleACPIPlatformExpert/BAT0/AppleSmartBatteryManager/AppleSmartBattery

On this unit, ACPI only utilizes BIF (extended and extra flags are set to n in config). The serial number and device name are correctly reported here whens setting BIF and so is the manufacturer, however when you look at what has been result of constructAppleSerialNumber - things don't seem quite right. When calling setSerialNumber from setBatteryBIF, number is present as you can see from debug above. As FirmwareSerialNumber is presented as 0x1950 in IOReg, _SerialNumberSym can't be empty and therefore should return a valid numeric value to the calling method?

It used to show up OK with 1.55 I was using previously...

AFAIK, nothing has changed in serial# related code. If you think it has, go through the commit log and test...

I never quite understood what constructAppleSerialNumber is trying to do (I didn't write it), and have never looked into it in detail.

 

[TimeWalker]

AFAIK, nothing has changed in serial# related code. If you think it has, go through the commit log and test...

I never quite understood what constructAppleSerialNumber is trying to do (I didn't write it), and have never looked into it in detail.

All is does is concatenates two strings:- device name and serial number with a dash in between. Did look through the commits and nothing has changed indeed, perhaps a timing issue .. but then BST would have had a change to update it a later time, but it never does. I will try to build some of the earlier commits in between 1.60 and 1.55 that I know wasn't acting up like that. Keep you posted. At the end of the day, not something terribly crucial, just puzzling.

 

[TimeWalker]

Ok, that method did suffer changes - original pre-1.60 commit. The serial construct method used to be void and wasn't being passed any args. It was being called from setBatteryBST, which at the time already had fDeviceName and fSerialNumber from evaluating BIF using setBatteryBIF earlier .. not the most elegant solution. Currently, the method is called with 2 args, having the results returned from respective methods, which apparently works for device name, but not for the serial number?

I've also noticed that the battery is no longer reported as 'service battery' with 1.60+

P.S. As dumb as it is, this solves the problem:

diff --git a/AppleSmartBatteryManager/AppleSmartBattery.cpp b/AppleSmartBatteryManager/AppleSmartBattery.cpp
index 7d78daf..a6bad62 100644
--- a/AppleSmartBatteryManager/AppleSmartBattery.cpp
+++ b/AppleSmartBatteryManager/AppleSmartBattery.cpp
@@ -1108,7 +1108,7 @@ void AppleSmartBattery::setSerialNumber(const OSSymbol *sym)

 OSSymbol *AppleSmartBattery::serialNumber(void)
 {
-    return OSDynamicCast(OSSymbol, properties->getObject(_SerialNumberSym));
+    return OSDynamicCast(OSSymbol, properties->getObject(_HardwareSerialSym));
 }

 void AppleSmartBattery::setManufacturerData(uint8_t *buffer, uint32_t bufferSize)

 

[RehabMan]

Ok, that method did suffer changes - original pre-1.60 commit. The serial construct method used to be void and wasn't being passed any args. It was being called from setBatteryBST, which at the time already had fDeviceName and fSerialNumber from evaluating BIF using setBatteryBIF earlier .. not the most elegant solution. Currently, the method is called with 2 args, having the results returned from respective methods, which apparently works for device name, but not for the serial number?

Which commit are you saying has this change?

I'll check on my laptops to see if I notice anything strange (I do know battery status is working just fine, as I generally keep all kexts up-to-date).

I've also noticed that the battery is no longer reported as 'service battery' with 1.60+

If your DSDT was one of those that reports data not acceptable to OS X, there is new code in the kext that corrects the various capacities to insure CurrentCapacity<=MaxCapacity<=DesignCapacity.

 

[TimeWalker]

Which commit are you saying has this change?

It's the one I've linked to in the post, this would be the exact place: 469517ba2d54b844371b9a30081fb6830980ef8b - 'ACPI-based configuration' et al.

If your DSDT was one of those that reports data not acceptable to OS X, there is new code in the kext that corrects the various capacities to insure CurrentCapacity<=MaxCapacity<=DesignCapacity.

No, it's not that. The battery has indeed seen better times, the capacities are reported OK and even with all the corrective flags left at default setting the indication is now back again, after having applied the diff I've posted above.

 

[RehabMan]

It's the one I've linked to in the post, this would be the exact place: 469517ba2d54b844371b9a30081fb6830980ef8b - 'ACPI-based configuration' et al.

OK... will check into it.

No, it's not that. The battery has indeed seen better times, the capacities are reported OK and even with all the corrective flags left at default setting the indication is now back again, after having applied the diff I've posted above.

So you get "correct" service battery indication with the old serial# code, and it goes away with the new (and incorrect code)...

Attach ioreg in both scenarios...

Attach ioreg as ZIP: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

 

[TimeWalker]

So you get "correct" service battery indication with the old serial# code, and it goes away with the new (and incorrect code)...
Attach ioreg in both scenarios...

Yeah, I guess it has to do with Apple software treating the battery having a valid serial number properly, whereas a number that is part unknown doesn't result in the 'service battery' indication. Like I said, the diff I've posted earlier is the only code change I've done (hw) compared to the original code (sw). No direct changes to the construct method what so ever.

 

[RehabMan]

Yeah, I guess it has to do with Apple software treating the battery having a valid serial number properly, whereas a number that is part unknown doesn't result in the 'service battery' indication. Like I said, the diff I've posted earlier is the only code change I've done (hw) compared to the original code (sw). No direct changes to the construct method what so ever.

Both these ioreg show ACPIBatteryManager 1.70.0. Need to see ioreg with old ACPIBatteryManager...