[SOLVED] 4x40s not sleeping on AC adapter power

[jaymeeduardo]

4x40s not sleeping on battery power

jaymeeduardo = yes, I thought it was solved, but there are some strange things. After ticking that option my first sleep under power worked, but on others just black screen. And, like you, I discovered if you pull the power plug after you have asked it to sleep then it will go to sleep. Put power plug back in and it will stay asleep until you wake it up normally.

For definite though when the battery patch is NOT there, sleep is always normal. So we need to maybe look to the DSDT battery patch or perhaps the battery kext? I did try just trashing the battery kext but it did not seem to solve the problem, so maybe an alternative battery patch is needed or there is something else in the DSDT that needs to be patched but is not there.

i replaces battery kexts with the hp probook installer 5, the one that used to work. same issue.

 

[RehabMan]

4x40s not sleeping on battery power

i replaces battery kexts with the hp probook installer 5, the one that used to work. same issue.

Yeah, I didn't think it was the battery manager either. Can you verify that it does work w/o the battery patch? If that is consistent and reproducible, that might give a focus area.

 

[minihack]

4x40s not sleeping on battery power

Hi Rehabman,

Thanks for sorting out different thread - could you re-title to not sleeping on mains power please.

I have got no further with testing yet as other life got in the way. The only thing I can say for sure at the moment though is that removing the battery patch solves the issue but obviously it is not a desirable solution.....and of course maybe it reveals that I need another patch.

What are the usual sleeping patches for the DSDT? Maybe I am missing one of those.

 

[RehabMan]

4x40s not sleeping on AC adapter power

Hi Rehabman,

Thanks for sorting out different thread - could you re-title to not sleeping on mains power please.

I have got no further with testing yet as other life got in the way. The only thing I can say for sure at the moment though is that removing the battery patch solves the issue but obviously it is not a desirable solution.....and of course maybe it reveals that I need another patch.

What are the usual sleeping patches for the DSDT? Maybe I am missing one of those.

If removing the battery patch solves the issue (that should be verified). Then it is just a matter of figuring out why. So verify the it is really the case:

- generate two DSDTs each with exactly the same starting point (fresh extract) but one with and one without the battery patch (post them here, along with the raw extract dsdt)
- remove /S/L/E/AppleSmartBatteryManager.kext to take it out of the equation completely.
- repair perms & rebuild caches
- swap the DSDTs to be sure your theory is correct. multiple times to make sure it is not a fluke.
- if it is confirmed, add /S/L/E/AppleSmartBatterManager.kext back in. Again test the two DSDTs.
- report the results for the four configurations

 

[minihack]

4x40s not sleeping on AC adapter power

I don't believe it is the battery kext, as removing seemed to give no difference.

Significant stuff uploaded though to see if you have any ideas.

In the folder is a DSDT before applying the battery patch, the battery patch itself for you to look at, and then the same DSDT after applying the patch.

Behaviour is normal sleep at all times and conditions repeated at least half a dozen times for the "before patch" version.

With "after patch" version on AC power the FIRST sleep under AC power after swapping the DSDTs and doing a restart gives normal sleep. However after waking the Probook from that first normal sleep any subsequent attempts at sleep (Apple menu sleep is what was used each time) result in screen going dark, but not sleeping and any key will bring screen back up. Tried leaving a few minutes to see if it was just going to sleep slowly, but that seemed to not make any difference to the behaviour.

Both versions seem to give normal sleep when on battery power alone.

 

[RehabMan]

4x40s not sleeping on AC adapter power

I don't believe it is the battery kext, as removing seemed to give no difference.

Significant stuff uploaded though to see if you have any ideas.

In the folder is a DSDT before applying the battery patch, the battery patch itself for you to look at, and then the same DSDT after applying the patch.

Behaviour is normal sleep at all times and conditions repeated at least half a dozen times for the "before patch" version.

With "after patch" version on AC power the FIRST sleep under AC power after swapping the DSDTs and doing a restart gives normal sleep. However after waking the Probook from that first normal sleep any subsequent attempts at sleep (Apple menu sleep is what was used each time) result in screen going dark, but not sleeping and any key will bring screen back up. Tried leaving a few minutes to see if it was just going to sleep slowly, but that seemed to not make any difference to the behaviour.

Both versions seem to give normal sleep when on battery power alone.

What about sleep w/ battery patch after cold boot? Same as first after restart or same as second sleep?

 

[minihack]

4x40s not sleeping on AC adapter power

.....same as second sleep...

 

[minihack]

4x40s not sleeping on AC adapter power

i find it interesting though that if you try and sleep it under AC power, removing the plug after the screen goes black lets it enter sleep and that you can then plug it in and it will remain asleep until you wake it normally.

 

[jaymeeduardo]

4x40s not sleeping on AC adapter power

i find it interesting though that if you try and sleep it under AC power, removing the plug after the screen goes black lets it enter sleep and that you can then plug it in and it will remain asleep until you wake it normally.

well thats what i told you. but i found the problem is not related to kext because i used a kext from my backup in which sleep on ac worked previously nothing happened still get the issue

 

[RehabMan]

4x40s not sleeping on AC adapter power

Got programming experience?

One thing you might try doing is experiment with modifications to the _PTS method (ACPI Prepare To Sleep). If you search your DSDT for Method (_PTS), you'll see that it mostly calls HPTS. Searching for HPTS, you'll find it at the top of the DSDT.

I would try commenting out different portions of this. Keep in mind that Arg0==3 for sleep (S3). In particular, I think the calls to SSMI don't really do anything and are perhaps not necessary (you could prove me wrong... I'm just guessing).

The goal of commenting stuff out of the _PTS would be, through process of elimination, determine if there is code here that is causing the stall or, and what code it is... I did a similar thing with my desktop DSDT, eventually determining there was some code attempting to talk to a non-existent PS2 port, causing sleep to take 2-3mins to enter.

Here is the code:

    Method (HPTS, 1, NotSerialized)
    {
        Store (Arg0, SLPT) // this is probably 100% necessary
        \_SB.ODGW (Or (0x5400, Arg0)) // not sure...
        If (LEqual (Arg0, 0x05)) // this is special case for restart (will never be reached if shutdown fix is applied [see below])
        {
            \_SB.SSMI (0xEA82, Arg0, Zero, Zero, Zero) // SSMI does nothing for us, I think...
        }

        If (LGreater (Arg0, Zero))
        {
            \_SB.SSMI (0xEA83, Zero, Zero, Zero, Zero)  // I don't think these calls do anything under OSX (I think some kind of callback into Windows WMI or something)
            Acquire (\_SB.PCI0.LPCB.EC0.ECMX, 0xFFFF) // this Acquire is new in 4x40
            If (\_SB.PCI0.LPCB.EC0.ECRG) // not sure what ECRG is but it is generally tested before touching any EC register...
            {
                Store (Zero, \_SB.PCI0.LPCB.EC0.HSST)
            }

            Release (\_SB.PCI0.LPCB.EC0.ECMX) // paired Release/Acquire new in 4x40
            PPTS (Arg0) // this results in another SSMI call
            If (LNotEqual (Arg0, 0x05)) // for all cases except restart
            {
                \_SB.PCI0.LPCB.EC0.BTDR (Zero)
                Store (0xFF, \_SB.PCI0.LPCB.EC0.NGBF) // these are just variables in memory (ACPI Name)
                Store (0xFF, \_SB.PCI0.LPCB.EC0.NGBT) // but related to battery...
                Store (0x07, \_SB.PCI0.LPCB.EC0.GACP)
                Store (One, \_SB.NFBS)
                If (LEqual (Arg0, 0x03))// this is specifically for sleep (s3)
                {
                    Store (\_SB.LID._LID (), LSTA)
                    If (LNotEqual (And (PNHM, 0x000F0FF0), 0x000106E0))
                    {
                        Store (APMC, IDPM)
                    }
                }
            }
        }
    }

And here is your _PTS:

    Method (_PTS, 1, NotSerialized)
    {
        HPTS (Arg0)
        If (LEqual (Arg0, 0x03))
        {
            If (LAnd (DTSE, LGreater (TCNT, One)))
            {
                TRAP (0x02, 0x1E)
            }
        }

        If (LOr (LEqual (Arg0, 0x04), LEqual (Arg0, 0x05))) // sleep state 4 and restart(soft-off)
        {
            If (LEqual (XHCI, 0x02)) // must be doing some USB3 related stuff
            {
                Store (0xFFFFFFF0, Local0)
                And (Local0, \_SB.PCI0.XHC.PR3, \_SB.PCI0.XHC.PR3)
            }
        }
    }

Why don't you have the "shutdown fix" for _PTS method? Shutdown fix:

#  Shutdown fix
into method label _PTS code_regex_not If\s\(LEqual\s\(Arg0,\s0x05\)\) code_regex ^((?:.|\n)*)$ replace_matched
begin
        If (LEqual (Arg0, 0x05)) {}\n
        Else\n
        {\n
%1
        }
end;

In addition there is still some "other than 8-bit EC register access" in the DSDT (I think the 4x30s still has these too). Just for grins, you could try patching. I really don't think this will help as I don't think that code is being reached. But see the attachment for an updated 06_Battery.txt...