[solved] T450 DUAL Battery Status help

RehabMan · Feb 23, 2017

tosbaha said:
That is what I am saying. In my hardware this assumption leads to non working battery state. You have two options, either you will add another if case, or create SSDT-BATCv2 in which this assumption is reversed. When I exchange this order, everything is working. I deleted my bad assumption about _BST after I realized the start of if block. Sorry for the confusion.

For the case of no batteries returning valid data (even though the _STA returns 0x1F), the code has to make an assumption about which _BST, or _BIF to return, or would need to become smarter about choosing "valid data" over "invalid data". Currently, it prioritizes the first battery checked and it isn't much smarter than that...

You will need to provide data that shows what you're doing.

I would suggest some well placed ACPIDebug traces in SSDT-BATC.dsl.

For example, in both BATC._BIF and BATC._BST:

Code:

                }
\rmdt.p2(Local0, Local2)
\rmdt.p2(Local1, Local3)
                // find primary and secondary battery
                If (0x1f != Local2 && 0x1f == Local3)

And at the return point of each:

Code:

                }
\rmdt.p2("Result", Local0)
                Return(Local0)

At least then you have some idea as to what the incoming data and outgoing data is...

I would need to see the resulting logs (eg. the early logs with invalid data) and "Problem Reporting" files.

tosbaha · Feb 23, 2017

Here is all the logs, DSDT BATC files. I put them in different folders. I hope you can see the major difference between two different SSDT-BATC file and the dramatic changes they cause. As I said before renaming BAT0 and BAT1 differently causes a problem. Therefore either there shouldn't be any assumptions and code should be generic or there should be two SSDT-BATC files just like I prepared in zip file.

RehabMan · Feb 24, 2017

tosbaha said:
Here is all the logs, DSDT BATC files. I put them in different folders. I hope you can see the major difference between two different SSDT-BATC file and the dramatic changes they cause. As I said before renaming BAT0 and BAT1 differently causes a problem. Therefore either there shouldn't be any assumptions and code should be generic or there should be two SSDT-BATC files just like I prepared in zip file.

Here is the mystery for you to solve...

Notice in nonworking1.rtf:

Code:

2017-02-24 01:41:34.476271+0300 0x82       Default     0x0                  0      kernel: (ACPIDebug) ACPIDebug: { "BATC_BIF Local0", { 0x0, 0xffffffff, 0xffffffff, 0x1, 0xffffffff, 0xa2, 0x0, 0x64, 0x0, "", "", "Lion", "Sony Corporation", }, "Local2", 0x0, }
2017-02-24 01:41:34.476445+0300 0x82       Default     0x0                  0      kernel: (ACPIDebug) ACPIDebug: { "BATC_BIF Local1", { 0x0, 0xffffffff, 0xffffffff, 0x1, 0xffffffff, 0xa1, 0x0, 0x64, 0x0, "", "", "Lion", "Sony Corporation", }, "Local3", 0x0, }
2017-02-24 01:41:34.476622+0300 0x82       Default     0x0                  0      kernel: (ACPIDebug) ACPIDebug: { "BATC_BIF Result", { 0x0, 0xffffffff, 0xffffffff, 0x1, 0xffffffff, 0xa2, 0x0, 0x64, 0x0, "", "", "Lion", "Sony Corporation", }, }

Note that the _STA result at that point for both is zero...
Since we already know that BATC._STA will return zero if both _STA return zero, and that ACPIBatteryManager.kext will not call _BIF/_BST when _STA reports zero, we know that the two _STA methods must have returned 0x1F.
Which means it is falling into a scenario where _BIF returns invalid data... and you can see the invalid data returned by _BIF.
So the problem originates in BAT1._BIF and BAT2._BIF, and presents SSDT-BATC with a scenario it is not designed to deal with (and furthermore, there is nothing it could do with this scenario).

Your task now is to determine by _BIF is not working correctly when BAT1._BIF is called first instead of BAT2._BIF.

tosbaha · Feb 24, 2017

I solved my issue by using alternative patch. Since alternative patch covers this issue by reversing the assumption of your code. Maybe you can add either alternative file or extra code to cover this case. If not let's note in here that your dsl has assumptions and it doesn't cover all cases. So another user with dual battery may try to rename batteries differently.

RehabMan · Feb 24, 2017

tosbaha said:
I solved my issue by using alternative patch. Since alternative patch covers this issue by reversing the assumption of your code. Maybe you can add either alternative file or extra code to cover this case. If not let's note in here that your dsl has assumptions and it doesn't cover all cases. So another user with dual battery may try to rename batteries differently.

What "alternative patch" are you referring to? (maybe you mean reversing the order of checks in the SSDT-BATC?)
Why do you not want to get at the root of the issue? You should dig into what is happening different in BAT1._BIF BAT2._BIF by using ACPIDebug.

The only thing I could add for your scenario (some dependency on BAT1 vs. BAT2 _BIF calls) would be to add a comment into SSDT-BATC.dsl. There is nothing that can be done to predict the order dependency your DSDT seems to have.

tosbaha · Feb 24, 2017

Yes reversing the order of batteries in SSDT-BATC file, fixes my problem. Logs prove that it works. Reversed order fixes the problem due to the way this file coded. I am using it for couple of days and it always worked. Only abnormality I see that for couple of seconds I see disabled or charging battery state with 0 percentage for a while in the first 10-12 seconds. However there was no error afterwards.

I attached that alternative SSDT-BATC file in previos zip file as well both as your version (BAT0 and BAT1) and mine (BAT1 and BAT2).

RehabMan · Feb 24, 2017

tosbaha said:
Yes reversing the order of batteries in SSDT-BATC file, fixes my problem. Logs prove that it works. Reversed order fixes the problem due to the way this file coded.

Nothing wrong with the way SSDT-BATC is coded.
Your logs prove the problem is in DSDT (some sort of order dependency).

I attached that alternative SSDT-BATC file in previos zip file as well both as your version (BAT0 and BAT1) and mine (BAT1 and BAT2).

You should try original SSDT-BATC.dsl, but reverse the order of the _STA/_BIF/_BST calls (eg. call BAT2 before BAT1) just to prove the order dependency in DSDT.

tosbaha · Feb 24, 2017

RehabMan said:
Nothing wrong with the way SSDT-BATC is coded.

Rehabman, I am trying to say that when the order of the batteries changed, call order of BAT functions changes which impacts the result. That is all I am saying. I also tried to "reverse the order of the _STA/_BIF/_BST calls", this also worked.

I compared _STA, _BIF and _BST of two batteries. _STA and _BST is same but _BIF differs by four lines. I added with comments in below code. You may check yourself maybe I missed something.

Code:

//BAT1.dsl _BIF
                            Store (B1B2 (XFC0, XFC1), Index (BPKG, 0x05)) //different
                            Store (One, Index (BPKG, 0x06)) //different
                            Store (Multiply (B1B2 (XDC0, XDC1), 0x0A), Index (BPKG, One))
                            Store (Multiply (B1B2 (XFC0, XFC1), 0x0A), Index (BPKG, 0x02))
                            Store (B1B2 (XDV0, XDV1), Index (BPKG, 0x04))
                            If (B1B2 (XFC0, XFC1))
                            {
                                Store (Divide (Multiply (B1B2 (XDC0, XDC1), 0x0A), 0x01F4, ), Index (BPKG, 0x07))
                                Store (Divide (Multiply (B1B2 (XDC0, XDC1), 0x0A), 0x01F4, ), Index (BPKG, 0x08))
                            }

//BAT2.dsl _BIF

                            Store (Multiply (B1B2 (YDC0, YDC1), 0x0A), Index (BPK2, One))
                            Store (Multiply (B1B2 (YFC0, YFC1), 0x0A), Index (BPK2, 0x02))
                            Store (B1B2 (YDV0, YDV1), Index (BPK2, 0x04))
                            If (B1B2 (YFC0, YFC1))
                            {
                                Store (B1B2 (YFC0, YFC1), Index (BPK2, 0x05)) //different
                                Store (One, Index (BPK2, 0x06)) //different
                                Store (Divide (Multiply (B1B2 (YDC0, YDC1), 0x0A), 0x01F4, ), Index (BPK2, 0x07))
                                Store (Divide (Multiply (B1B2 (YDC0, YDC1), 0x0A), 0x01F4, ), Index (BPK2, 0x08))
                            }

As far as I understand, BAT1 sets "Design capacity of warning" with XFC0 and XFC1 and sets "Design capacity of low" to one. Whereas BAT2 only sets "Design capacity of low" when it is enabled(?). I don't know but maybe because BAT2 is not enabled quickly, it can't set 0x5 and 0x6 and it causes the problem. Since BIF calls invalid design capacity result for BAT2. I really don't know anymore what is going on. All I know is that order of BAT functions fixes my problem.

As you said, maybe you can add a comment about changing the order of BAT names to fix this kind a issue.

RehabMan · Feb 25, 2017

tosbaha said:
Rehabman, I am trying to say that when the order of the batteries changed, call order of BAT functions changes which impacts the result. That is all I am saying. I also tried to "reverse the order of the _STA/_BIF/_BST calls", this also worked.

Yes. This fact is well established.
But it does not prove anything is wrong in SSDT-BATC.
It demonstrates/exposes a bug in your DSDT _BIF/_BST methods.

Code:
I compared _STA, _BIF and _BST of two batteries. _STA and _BST is same but _BIF differs by four lines. I added with comments in below code. You may check yourself maybe I missed something.

Code:

//BAT1.dsl _BIF Store (B1B2 (XFC0, XFC1), Index (BPKG, 0x05)) //different Store (One, Index (BPKG, 0x06)) //different Store (Multiply (B1B2 (XDC0, XDC1), 0x0A), Index (BPKG, One)) Store (Multiply (B1B2 (XFC0, XFC1), 0x0A), Index (BPKG, 0x02)) Store (B1B2 (XDV0, XDV1), Index (BPKG, 0x04)) If (B1B2 (XFC0, XFC1)) { Store (Divide (Multiply (B1B2 (XDC0, XDC1), 0x0A), 0x01F4, ), Index (BPKG, 0x07)) Store (Divide (Multiply (B1B2 (XDC0, XDC1), 0x0A), 0x01F4, ), Index (BPKG, 0x08)) } //BAT2.dsl _BIF Store (Multiply (B1B2 (YDC0, YDC1), 0x0A), Index (BPK2, One)) Store (Multiply (B1B2 (YFC0, YFC1), 0x0A), Index (BPK2, 0x02)) Store (B1B2 (YDV0, YDV1), Index (BPK2, 0x04)) If (B1B2 (YFC0, YFC1)) { Store (B1B2 (YFC0, YFC1), Index (BPK2, 0x05)) //different Store (One, Index (BPK2, 0x06)) //different Store (Divide (Multiply (B1B2 (YDC0, YDC1), 0x0A), 0x01F4, ), Index (BPK2, 0x07)) Store (Divide (Multiply (B1B2 (YDC0, YDC1), 0x0A), 0x01F4, ), Index (BPK2, 0x08)) }

As far as I understand, BAT1 sets "Design capacity of warning" with XFC0 and XFC1 and sets "Design capacity of low" to one. Whereas BAT2 only sets "Design capacity of low" when it is enabled(?). I don't know but maybe because BAT2 is not enabled quickly, it can't set 0x5 and 0x6 and it causes the problem. Since BIF calls invalid design capacity result for BAT2. I really don't know anymore what is going on. All I know is that order of BAT functions fixes my problem.

As you said, maybe you can add a comment about changing the order of BAT names to fix this kind a issue.

Did you verify that the _BIF/_BST code is not falling into one of these "early return" cases?

Code:

                            If (And (B1ST, 0x10))
                            {
                                Return (BPKG)
                            }

                            If (LNotEqual (B1DR, 0x3F))
                            {
                                Return (BPKG)
                            }

Note: The case in _BST is similar, but not exactly the same.

Recommend you investigate completely what your _BIF method is doing...

tosbaha · Feb 25, 2017

I boot my computer today but unfortunately "reverse the order of the _STA/_BIF/_BST calls" didn't work this time. I confirm 100% that only method working is changing the order of BAT1<->BAT2 in SSDT-BATC.aml file. I am sorry but I am really tired of debugging this issue. It has been a month now. It is working whether by my buggy DSDT, luck or voodoo magic. I really don't know. However, I really don't have any more time or patience to further debug this issue. I really appreciate the time you spend debugging this issue. Thanks and have a lovely weekend.

Search

[solved] T450 DUAL Battery Status help

RehabMan

Moderator

tosbaha

Attachments

RehabMan

Moderator

tosbaha

RehabMan

Moderator

tosbaha

RehabMan

Moderator

tosbaha

RehabMan

Moderator

tosbaha

Forum

Guides

Downloads