Contribute
Register

Lenovo y700 - Sierra

Status
Not open for further replies.
RehabMan said:
There are various ways...
No idea what you did wrong without the complete SSDT you're trying to compile.
Click to expand...

Ok, I'm attaching SSDT-HACK and SSDT-15 (Graphics).
There is also missing VREG & VGAB, I don't know if I should just copy them into Scope or somehow register as External also?

RehabMan said:
You didn't have to rename it because you were patching it.
Did you read ACPI hotpatch guide, "Rename and Replace"?
Click to expand...

Yea, but _REG is only in DSDT.aml it's still loaded by Clover with DropOem=false from ACPI/patched, right? So I can just patch _REG with the EC call as usual, can't I?


Calling _OFF from _INI is the same.
Code: 
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI Calling _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed CCHK - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT-DISCRETE"
kernel: (ACPIDebug) ACPIDebug: "PEGP Calling _OFF - SSDT-DISCRETE"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed CCHK - SSDT-15"
 

Attachments

  • SSDT.zip
    14.3 KB · Views: 114
Last edited:
EvulMastah said:
Ok, I'm attaching SSDT-HACK and SSDT-15 (Graphics).
There is also missing VREG & VGAB, I don't know if I should just copy them into Scope or somehow register as External also?
Click to expand...

The "Existing object has invalid type for Scope operator (\_SB.PCI0.PEG0.PEGP [Untyped])" is because you forgot to declare the type for PEGP with External:
Code: 
    External(\_SB.PCI0.PEG0.PEGP, DeviceObj)

VREG and VGAB cannot be reached without External:
Code: 
External(\_SB.PCI0.PEG0.PEGP.VREG, FieldUnitObj)
External(\_SB.PCI0.PEG0.PEGP.VGAB, IntObj)

Yea, but _REG is only in DSDT.aml it's still loaded by Clover with DropOem=false from ACPI/patched, right? So I can just patch _REG with the EC call as usual, can't I?
Click to expand...

Yes... because you're not doing hotpatch for your DSDT...

Calling _OFF from _INI is the same.
Code: 
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI Calling _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed CCHK - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT-DISCRETE"
kernel: (ACPIDebug) ACPIDebug: "PEGP Calling _OFF - SSDT-DISCRETE"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF - SSDT-15"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed CCHK - SSDT-15"
Click to expand...

So, yes, it seems that trying to set an EC scoped SystemMemory field does not work until _REG is called...
At least that will be the theory for now...
 
RehabMan said:
Yes... because you're not doing hotpatch for your DSDT...
Click to expand...

I am patching DSDT with brightness fix, brightness keys etc manually anyway, so it is not vanilla.

RehabMan said:
So, yes, it seems that trying to set an EC scoped SystemMemory field does not work until _REG is called...
At least that will be the theory for now...
Click to expand...

Great news! Nvidia got disabled :)
Code: 
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT"
kernel: (ACPIDebug) ACPIDebug: "PEGP _INI - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP Calling _OFF - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed CCHK - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP passed Sleep - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP GPRF not equal One - SSDT-HACK"
kernel: (ACPIDebug) ACPIDebug: "PEGP _OFF Completed - SSDT-HACK"

It is not listed in System Report.
Seems like I can go back to DropOem=false and create a hotpach for _OFF -> XOFF for Nvidia device...

The shutdown is still not working, but I will get back with the files when I'm back to the DropOem=false way, unless the RMDT will be handy for the shutdown?
 
RehabMan said:
What happens with Apple->Shutdown?
Click to expand...

Something like an "infinite loop" behaviour. When the screen turns off, after a while CPU fans kicks in at max speed and it stays like that. I gave it a good few minutes and it never shut down. I will report back with the files after I'm done with the hotpatching SSDT-15, unless the debugger will be handy. (I have not applied any "Shutdown Fix" patches)
 
EvulMastah said:
Something like an "infinite loop" behaviour. When the screen turns off, after a while CPU fans kicks in at max speed and it stays like that. I gave it a good few minutes and it never shut down. I will report back with the files after I'm done with the hotpatching SSDT-15, unless the debugger will be handy. (I have not applied any "Shutdown Fix" patches)
Click to expand...

You should try a shutdown fix.
 
RehabMan said:
You should try a shutdown fix.
Click to expand...

Applied Shutdown fix v2, did not help. Gave it more than 2 minutes.

Also, the Nvidia disable patch extended the time it requires to sleep from ~14s to ~33s. Is this covered in "Sleep/Wake Problems" of disabling discrete card guide? Because it does not mention what are the problems.
Edit: I think the times are pretty random. Got ~19s now. What I have spotted is, after wake my bluetooth device gets enabled.

Commands:
Code: 
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc
kextstat|grep -y applehda
   13    2 0xffffff7f83007000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (5.0) 65E05472-6AE7-3308-8CC8-FA6CB0DB2AEE <12 11 7 6 5 4 3 1>
   90    0 0xffffff7f82f2a000 0x1d000    0x1d000    com.apple.driver.AppleHDAController (279.48) ED51F180-19C8-3DE1-AF81-0E389D98ADDE <89 88 79 12 7 6 5 4 3 1>

Code: 
sudo touch /System/Library/Extensions && sudo kextcache -u /
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Trackpad.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Mouse.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Keyboard.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Controller.kext
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 FakeSMC.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 CodecCommander.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 -67013 0xFFFFFFFFFFFEFA3B for kext AppleMobileDevice.kext
kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext aDummyHDA.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIDebug.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIBatteryManager.kext
KernelCache ID: 108DD76D16162C601AFD9A0C8AC441DA
 

Attachments

  • CLOVER.zip
    2 MB · Views: 146
  • FagBook.ioreg.zip
    726.2 KB · Views: 86
  • patchmatic.zip
    57.2 KB · Views: 107
EvulMastah said:
Applied Shutdown fix v2, did not help. Gave it more than 2 minutes.

Also, the Nvidia disable patch extended the time it requires to sleep from ~14s to ~33s. Is this covered in "Sleep/Wake Problems" of disabling discrete card guide? Because it does not mention what are the problems.
Edit: I think the times are pretty random. Got ~19s now. What I have spotted is, after wake my bluetooth device gets enabled.

Commands:
Code: 
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc
kextstat|grep -y applehda
   13    2 0xffffff7f83007000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (5.0) 65E05472-6AE7-3308-8CC8-FA6CB0DB2AEE <12 11 7 6 5 4 3 1>
   90    0 0xffffff7f82f2a000 0x1d000    0x1d000    com.apple.driver.AppleHDAController (279.48) ED51F180-19C8-3DE1-AF81-0E389D98ADDE <89 88 79 12 7 6 5 4 3 1>

Code: 
sudo touch /System/Library/Extensions && sudo kextcache -u /
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Trackpad.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Mouse.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Keyboard.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext VoodooPS2Controller.kext
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 FakeSMC.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 CodecCommander.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 -67013 0xFFFFFFFFFFFEFA3B for kext AppleMobileDevice.kext
kext-dev-mode allowing invalid signature -67030 0xFFFFFFFFFFFEFA2A for kext aDummyHDA.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIDebug.kext
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIBatteryManager.kext
KernelCache ID: 108DD76D16162C601AFD9A0C8AC441DA
Click to expand...

Time to sleep after Apple->Sleep is typical at 15-20sec (as per Apple design... same on real Macs).
Your ACPI is not patched correctly... you have no accommodation for _OSI("Darwin").
Need an "OS Check Fix" patch or _OSI->XOSI + SSDT-XOSI.aml.
 
RehabMan said:
Need an "OS Check Fix" patch or _OSI->XOSI + SSDT-XOSI.aml
Click to expand...

Hm? I am using _OSI->XOSI (config.plist) and XOSI part is in SSDT-HACK.aml.

config.plist:
Code: 
                <dict>
                    <key>Comment</key>
                    <string>change _OSI to XOSI</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>X09TSQ==</data>
                    <key>Replace</key>
                    <data>WE9TSQ==</data>
                </dict>

SSDT-HACK.dsl (XOSI part):
Code: 
    Method(XOSI, 1)
    {
        // simulation targets
        // source: (google 'Microsoft Windows _OSI')
        //  http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
        Store(Package()
        {
            "Windows",              // generic Windows query
            "Windows 2001",         // Windows XP
            "Windows 2001 SP2",     // Windows XP SP2
            //"Windows 2001.1",     // Windows Server 2003
            //"Windows 2001.1 SP1", // Windows Server 2003 SP1
            "Windows 2006",         // Windows Vista
            "Windows 2006 SP1",     // Windows Vista SP1
            //"Windows 2006.1",     // Windows Server 2008
            "Windows 2009",         // Windows 7/Windows Server 2008 R2
            "Windows 2012",         // Windows 8/Windows Server 2012
            //"Windows 2013",       // Windows 8.1/Windows Server 2012 R2
            //"Windows 2015",       // Windows 10/Windows Server TP
        }, Local0)
        Return (Ones != Match(Local0, MEQ, Arg0, MTR, 0, 0))
    }

Or am I missing "Darwin" in XOSI Package?
 
EvulMastah said:
Hm? I am using _OSI->XOSI (config.plist) and XOSI part is in SSDT-HACK.aml.

config.plist:
Code: 
                <dict>
                    <key>Comment</key>
                    <string>change _OSI to XOSI</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>X09TSQ==</data>
                    <key>Replace</key>
                    <data>WE9TSQ==</data>
                </dict>

SSDT-HACK.dsl (XOSI part):
Code: 
    Method(XOSI, 1)
    {
        // simulation targets
        // source: (google 'Microsoft Windows _OSI')
        //  http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
        Store(Package()
        {
            "Windows",              // generic Windows query
            "Windows 2001",         // Windows XP
            "Windows 2001 SP2",     // Windows XP SP2
            //"Windows 2001.1",     // Windows Server 2003
            //"Windows 2001.1 SP1", // Windows Server 2003 SP1
            "Windows 2006",         // Windows Vista
            "Windows 2006 SP1",     // Windows Vista SP1
            //"Windows 2006.1",     // Windows Server 2008
            "Windows 2009",         // Windows 7/Windows Server 2008 R2
            "Windows 2012",         // Windows 8/Windows Server 2012
            //"Windows 2013",       // Windows 8.1/Windows Server 2012 R2
            //"Windows 2015",       // Windows 10/Windows Server TP
        }, Local0)
        Return (Ones != Match(Local0, MEQ, Arg0, MTR, 0, 0))
    }

Or am I missing "Darwin" in XOSI Package?
Click to expand...

OK... I didn't see it in SSDT-HACK. If that's what you're doing, then it is fine.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top