Contribute
Register

[Solved] EC _Qxx keys not working on cold boot

Status
Not open for further replies.

the-braveknight

Moderator
Joined
Nov 24, 2015
Messages
1,220
Motherboard
Lenovo Legion Y520 (Clover)
CPU
i7-7700HQ
Graphics
HD 630 (1920x1080) + Nvidia GTX 1060
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Hello @RehabMan,
For a quite long time, my guide has been suffering from a problem that's causing my EC _Q11 & _Q12 not to work on cold boot, I can fix that only by booting into Windows, then restating to macOS, or simply by putting my machine to sleep then wake it up.

I found out that my problem is somehow related to SSDT-NVDA that's meant to disable my nVidia discrete card, because when I removed it, the issue disappeared.
I've been searching for any error in my SSDT-NVDA but I just couldn't find what's wrong.

Would you please take a look?

Thanks.


Terminal output:
Code:
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext USBInjectAll.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext RealtekRTL8111.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext IntelBacklight.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakeSMC.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HD_Graphics.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Broadcom_WiFi.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmPatchRAM2.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmFirmwareRepo.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2Keyboard.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2Controller.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2SmartTouchPad.kext

kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext AppleHDA_CX20751.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIBatteryManager.kext

kext-dev-mode allowing invalid signature -67013 0xFFFFFFFFFFFEFA3B for kext AppleMobileDevice.kext

KernelCache ID: 911409749310239C4C1C1A0B652C5FAB

symlink("/System/Library/PrelinkedKernels/prelinkedkernel", "/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache") failed 17 (File exists) <createPrelinkedKernel 2795>

Terminal output:
Code:
Zaids-macOS:~ Zaid$ kextstat|grep -y acpiplat

   13    2 0xffffff7f830f2000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (5.0) 867C81BE-EA01-3A65-89F4-06D78E6514CA <12 11 7 6 5 4 3 1>

Zaids-macOS:~ Zaid$ kextstat|grep -y appleintelcpu

Zaids-macOS:~ Zaid$ kextstat|grep -y applelpc

  110    0 0xffffff7f82bfc000 0x3000     0x3000     com.apple.driver.AppleLPC (3.1) F51595F0-F9B1-3B85-A1C3-F984DAD4107E <91 12 5 4 3>

Zaids-macOS:~ Zaid$
 

Attachments

  • RehabMan.zip
    40.1 KB · Views: 63
  • SSDT-NVDA.dsl
    2 KB · Views: 120
  • CLOVER.zip
    1.5 MB · Views: 105
  • Zaid's macOS.ioreg
    5.4 MB · Views: 121
Hello @RehabMan,
For a quite long time, my guide has been suffering from a problem that's causing my EC _Q11 & _Q12 not to work on cold boot, I can fix that only by booting into Windows, then restating to macOS, or simply by putting my machine to sleep then wake it up.

I found out that my problem is somehow related to SSDT-NVDA that's meant to disable my nVidia discrete card, because when I removed it, the issue disappeared.
I've been searching for any error in my SSDT-NVDA but I just couldn't find what's wrong.

Would you please take a look?

Thanks.


Terminal output:
Code:
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext USBInjectAll.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext RealtekRTL8111.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext IntelBacklight.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakeSMC.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Intel_HD_Graphics.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID_Broadcom_WiFi.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext FakePCIID.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmPatchRAM2.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext BrcmFirmwareRepo.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2Keyboard.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2Controller.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ApplePS2SmartTouchPad.kext

kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext AppleHDA_CX20751.kext

kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIBatteryManager.kext

kext-dev-mode allowing invalid signature -67013 0xFFFFFFFFFFFEFA3B for kext AppleMobileDevice.kext

KernelCache ID: 911409749310239C4C1C1A0B652C5FAB

symlink("/System/Library/PrelinkedKernels/prelinkedkernel", "/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache") failed 17 (File exists) <createPrelinkedKernel 2795>

Terminal output:
Code:
Zaids-macOS:~ Zaid$ kextstat|grep -y acpiplat

   13    2 0xffffff7f830f2000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (5.0) 867C81BE-EA01-3A65-89F4-06D78E6514CA <12 11 7 6 5 4 3 1>

Zaids-macOS:~ Zaid$ kextstat|grep -y appleintelcpu

Zaids-macOS:~ Zaid$ kextstat|grep -y applelpc

  110    0 0xffffff7f82bfc000 0x3000     0x3000     com.apple.driver.AppleLPC (3.1) F51595F0-F9B1-3B85-A1C3-F984DAD4107E <91 12 5 4 3>

Zaids-macOS:~ Zaid$

In _REG I suggest only doing the Store(0,GATY) when the EC has become available (Arg0==3 && Arg1==1).
Also, you might try calling _ON from _PTS and XOFF from _WAK.
 
In _REG I suggest only doing the Store(0,GATY) when the EC has become available (Arg0==3 && Arg1==1).
I'm not sure I know enough ACPI to do that. Can you show me how?

Also, you might try calling _ON from _PTS and XOFF from _WAK.
I didn't have to do that back then when I was using static patching, so I don't think I need to do that. I'll try doing what you suggested first, then maybe try this if that doesnt work.

EDIT: Is this how I'd do it?
Code:
Method (_REG, 2, NotSerialized)
{
    \_SB.PCI0.LPCB.EC0.XREG(Arg0, Arg1)
    If (ECON)
    {
        If(Arg0 == 3 && Arg1 == 1)
        {
            \_SB.PCI0.LPCB.EC0.GATY = Zero
        }
    }
}
 
I'm not sure I know enough ACPI to do that. Can you show me how?

It is covered in the DGPU disable guide.

I didn't have to do that back then when I was using static patching, so I don't think I need to do that. I'll try doing what you suggested first, then maybe try this if that doesnt work.

EDIT: Is this how I'd do it?
Code:
Method (_REG, 2, NotSerialized)
{
    \_SB.PCI0.LPCB.EC0.XREG(Arg0, Arg1)
    If (ECON)
    {
        If(Arg0 == 3 && Arg1 == 1)
        {
            \_SB.PCI0.LPCB.EC0.GATY = Zero
        }
    }
}

If your static patch scenario didn't have this problem, you should probably go back to static patch so you can compare/verify this assertion.

Note: No need for the ECON check. ECON should be non-zero upon _REG completion. You can verify with ACPIDebug.kext.
 
It is covered in the DGPU disable guide.



If your static patch scenario didn't have this problem, you should probably go back to static patch so you can compare/verify this assertion.
My static patching scenario did not have this problem. In fact, even my one (SSDT-HACK) SSDT did not have this problem... I'm just not sure why I'm having it now... that's why I'm confused. Can it be related to how I'm declaring objects with 'External'? But I checked every single object many times and verified they're correctly addressed.

Note: No need for the ECON check. ECON should be non-zero upon _REG completion. You can verify with ACPIDebug.kext.
I have the ECON check because I had it earlier with my static patching scenario...

Any further ideas?
 
My static patching scenario did not have this problem. In fact, even my one (SSDT-HACK) SSDT did not have this problem... I'm just not sure why I'm having it now... that's why I'm confused. Can it be related to how I'm declaring objects with 'External'? But I checked every single object many times and verified they're correctly addressed.


I have the ECON check because I had it earlier with my static patching scenario...

Any further ideas?

Go back to static patch to verify.
Initially, you can static patch just the Nvidia disable part...
 
Go back to static patch to verify.
Initially, you can static patch just the Nvidia disable part...
I removed the _REG code from the SSDT and eliminated _REG -> XREG patch from my config.plist and the issue seems to have disappeared and my nVidia card is still disabled. Is it OK not to include the code removed from _OFF in the _REG?

code
Code:
Method (_OFF, 0, Serialized)
...
If (\ECON)
{
    Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
}
...
 
I removed the _REG code from the SSDT and eliminated _REG -> XREG patch from my config.plist and the issue seems to have disappeared and my nVidia card is still disabled. Is it OK not to include the code removed from _OFF in the _REG?

code
Code:
Method (_OFF, 0, Serialized)
...
If (\ECON)
{
    Store (Zero, \_SB.PCI0.LPCB.EC0.GATY)
}
...

Were you not doing that _REG patch in your static patch scenario?
 
Were you not doing that _REG patch in your static patch scenario?
I used to do it. But back then I followed a guide step-by-step and I did not know what I was doing and why, I had no knowledge.
I do not want to go back to the static patching scenario because I don't believe the guide I followed did it correctly.

So my question is: Is the _REG patch really needed? If so, what exactly would I add to the _REG? And how would I correctly call original _REG (XREG) from the patched _REG so that I won't have to write the same code again in the patched _REG?
 
I used to do it. But back then I followed a guide step-by-step and I did not know what I was doing and why, I had no knowledge.
I do not want to go back to the static patching scenario because I don't believe the guide I followed did it correctly.

So my question is: Is the _REG patch really needed? If so, what exactly would I add to the _REG? And how would I correctly call original _REG (XREG) from the patched _REG so that I won't have to write the same code again in the patched _REG?

You will need to decide for yourself whether you need the EC related code to execute or not...
It could be that the code you moved is somehow dependent on being executed within the context of the original _OFF.
 
Status
Not open for further replies.
Back
Top