Help on dropping SSDTs

[m.gbt2]

nguyenmac, I'm sorry to be slightly off-topic here, but I still believe it may be the best place to ask. I didn't follow your first post for SSDT creation, actually I created mine from ssdtPRGen.sh.
I'm looking for info on how to correctly drop SSDT tables on Clover now. These are my beliefs: as the TableId from the generated SSDT is CpuPm, then I must drop CpuPm and rename the generated SSDT to the name of my original SSDT with CpuPm as TableId. I mean, I dumped all my SSDTs using Clover, then I see that SSDT-2.aml is the one with TableId = CpuPm, so I rename the generated one to SSDT-2.aml and put it into the patched folder. Now my beliefs are probably incorrect as that differ a little from your first post, and also from what a Clover developer friend told me.

In post #1 you say to use the name SSDT.aml and drop both Cpu0Ist and CpuPm.
In the meanwhile my friend says in my case I should drop only Cpu0Ist and then name the file to SSDT-1.aml as this is the one relative to Cpu0Ist.

I have actually tried all of the above and I don't see differences in the power management: AICPUPMI reports all levels (8-23 for my processor) in every case (although HWMonitor and Intel Power Gadget for some reason don't pass 2000MHz, and my turbo frequency is 2300MHz). Coincidence or not, the only time I noticed a performance gain was when I tried DropOemSSDT. NovaBench performed better than ever, although AICPUPMI and the mentioned apps kept their outputs.

This SSDT thing is stressing me out because I'm looking for a reason of my not fully functional sleep. All of the components turn off, except the CPU (after hours and hours it is still hot and draining the battery). Sleep states are detected during boot (S3 S4 S5).

I'm really sorry for the big post but I tried to give you all the details I can. Thank you very much!

 

[RehabMan]

Guide To Install Mavericks with Clover Bootloader

nguyenmac, I'm sorry to be slightly off-topic here, but I still believe it may be the best place to ask. I didn't follow your first post for SSDT creation, actually I created mine from ssdtPRGen.sh.
I'm looking for info on how to correctly drop SSDT tables on Clover now. These are my beliefs: as the TableId from the generated SSDT is CpuPm, then I must drop CpuPm and rename the generated SSDT to the name of my original SSDT with CpuPm as TableId. I mean, I dumped all my SSDTs using Clover, then I see that SSDT-2.aml is the one with TableId = CpuPm, so I rename the generated one to SSDT-2.aml and put it into the patched folder. Now my beliefs are probably incorrect as that differ a little from your first post, and also from what a Clover developer friend told me.

In post #1 you say to use the name SSDT.aml and drop both Cpu0Ist and CpuPm.
In the meanwhile my friend says in my case I should drop only Cpu0Ist and then name the file to SSDT-1.aml as this is the one relative to Cpu0Ist.

I have actually tried all of the above and I don't see differences in the power management: AICPUPMI reports all levels (8-23 for my processor) in every case (although HWMonitor and Intel Power Gadget for some reason don't pass 2000MHz, and my turbo frequency is 2300MHz). Coincidence or not, the only time I noticed a performance gain was when I tried DropOemSSDT. NovaBench performed better than ever, although AICPUPMI and the mentioned apps kept their outputs.

This SSDT thing is stressing me out because I'm looking for a reason of my not fully functional sleep. All of the components turn off, except the CPU (after hours and hours it is still hot and draining the battery). Sleep states are detected during boot (S3 S4 S5).

I'm really sorry for the big post but I tried to give you all the details I can. Thank you very much!

You should drop all CPU PM related tables. On newer computers, there tends to be several, and they do not always have the tags as appropriate in the DSDT headers. So, you must examine all your tables to determine which ones to drop and how to drop them.

The technique I like to employ is to simply drop all OEM tables, then selectively include the ones you want to keep in ACPI/patched. This gives you the opportunity to patch them if you need to.

 

[nguyenmac]

Guide To Install Mavericks with Clover Bootloader

You should drop all CPU PM related tables. On newer computers, there tends to be several, and they do not always have the tags as appropriate in the DSDT headers. So, you must examine all your tables to determine which ones to drop and how to drop them.

The technique I like to employ is to simply drop all OEM tables, then selectively include the ones you want to keep in ACPI/patched. This gives you the opportunity to patch them if you need to.

+1.

When I drop all tables, it will also drop BGRT table. I don't know exactly the role of all tables.

I tried once to drop all oem ssdt in config.plist instead of 2 CPU tables, and it caused problem with HP 2170p. You can see more detail here:

http://www.tonymacx86.com/hp-probook-mavericks/117856-hp-elitebook-2170p-mavericks-3.html#post718677

http://www.tonymacx86.com/hp-probook-mavericks/117856-hp-elitebook-2170p-mavericks-3.html#post718755

 

[m.gbt2]

Guide To Install Mavericks with Clover Bootloader

You should drop all CPU PM related tables. On newer computers, there tends to be several, and they do not always have the tags as appropriate in the DSDT headers. So, you must examine all your tables to determine which ones to drop and how to drop them.

So, my "origin" SSDTs are:
SSDT-0 = PtidDevc
SSDT-1 = Cpu0Ist
SSDT-2 = CpuPm
SSDT-3x = ApIst
SSDT-4x = Cpu0Cst
SSDT-5x = ApCst
I'm currently dropping Cpu0Ist and CpuPm. Should I also drop Cpu0Cst then? I mean, I really don't have enough knowledge to understand by myself if pike's SSDT script is generating enough code to replace this or that table or even a few of them...
edit: by dropping Cpu0Ist, CpuPm and Cpu0Cst I have the same best benchmark results I got previously when dropping all possible tables so this is probably optimal at least in the performance point of view.

The technique I like to employ is to simply drop all OEM tables, then selectively include the ones you want to keep in ACPI/patched. This gives you the opportunity to patch them if you need to.

Seems legit, but at the same time too complicated. That seems to require years of experience until you know every table and discover how to analyse and deal with every detail on it...

 

[RehabMan]

Guide To Install Mavericks with Clover Bootloader

So, my "origin" SSDTs are:
SSDT-0 = PtidDevc
SSDT-1 = Cpu0Ist
SSDT-2 = CpuPm
SSDT-3x = ApIst
SSDT-4x = Cpu0Cst
SSDT-5x = ApCst
I'm currently dropping Cpu0Ist and CpuPm. Should I also drop Cpu0Cst then? I mean, I really don't have enough knowledge to understand by myself if pike's SSDT script is generating enough code to replace this or that table or even a few of them...
edit: by dropping Cpu0Ist, CpuPm and Cpu0Cst I have the same best benchmark results I got previously when dropping all possible tables so this is probably optimal at least in the performance point of view.

I would drop all those tables. Most are CPU related, which Pike's script or Clover Generate can take care of. The PtidDevc is useful only to examine to see if you can figure out how to obtain fan speed/temperatures for ACPISensors.kext.

Seems legit, but at the same time too complicated. That seems to require years of experience until you know every table and discover how to analyse and deal with every detail on it...

You make educated guesses really.

 

[m.gbt2]

Guide To Install Mavericks with Clover Bootloader

You make educated guesses really.

Then years have past and now I'm searching on the SSDTs for every register declared as External in the DSDT. They weren't found or aren't Methods, except one:

External (\_PR_.CPU0._PPC)

In my SSDT-1 it is simply:

Name (_PPC, Zero)

So not to worry about, I believe. But in my SSDT-3x (Table ID ApIst) I see:

External (\_PR_.CPU0._PPC, IntObj)

    Scope (\_PR.CPU1)
    {
        Method (_PPC, 0, NotSerialized)
        {
            Return (\_PR.CPU0._PPC)
        }

As this external variable doesn't seem to have a sense in the SSDT-1, where it is defined, I believe this Method is also not needed. So I can finally conclude that I can really use DropOemSSDT?

 

[RehabMan]

Guide To Install Mavericks with Clover Bootloader

Then years have past and now I'm searching on the SSDTs for every register declared as External in the DSDT. They weren't found or aren't Methods, except one:

External (\_PR_.CPU0._PPC)

In my SSDT-1 it is simply:

Name (_PPC, Zero)

So not to worry about, I believe. But in my SSDT-3x (Table ID ApIst) I see:

External (\_PR_.CPU0._PPC, IntObj)

    Scope (\_PR.CPU1)
    {
        Method (_PPC, 0, NotSerialized)
        {
            Return (\_PR.CPU0._PPC)
        }

As this external variable doesn't seem to have a sense in the SSDT-1, where it is defined, I believe this Method is also not needed. So I can finally conclude that I can really use DropOemSSDT?

You do have to watch out for Externals. If they are accessed at runtime, the ACPI call will fail which could cause unpredictable results. It is best to review the code that accesses the variable to decide what to do with it. Usually you simply remove the code that accesses it.

 

[m.gbt2]

Guide To Install Mavericks with Clover Bootloader

You do have to watch out for Externals. If they are accessed at runtime, the ACPI call will fail which could cause unpredictable results. It is best to review the code that accesses the variable to decide what to do with it. Usually you simply remove the code that accesses it.

Ok, that register is present at _WAK and SPPC methods. I've seen this same register present in the same methods on a Dell DSDT that I have available too. How is it in your ProBook? If it exists in the original DSDT, did you make any modifications to it?

 

[RehabMan]

Guide To Install Mavericks with Clover Bootloader

Ok, that register is present at _WAK and SPPC methods. I've seen this same register present in the same methods on a Dell DSDT that I have available too. How is it in your ProBook? If it exists in the original DSDT, did you make any modifications to it?

There is a method PNOT and/or PPNT in DSDT that accesses some of the things in the CPU SSDTs. We fix it by removing all the code there:

# Fix method PPNT, called from AC adapter device (AC/ADP1) (ProBooks)
into method label PPNT parent_label EC0 replace_content begin // nothing end;
# Fix method PNOT, called from AC adapter device (AC/ADP1) (EliteBooks?)
into method label PNOT replace_content begin // nothing end;

My latest laptop is a Lenovo U430 and the _WAK/_PTS methods access some things in ssdt6.aml. It was causing the _WAK and _PTS methods to abort before executing completely (discovered by ACPIDebug traces at beginning and end of each method). Solution: include ssdt6.aml (along with others) in ACPI/patched.

 

[m.gbt2]

Guide To Install Mavericks with Clover Bootloader

Ok, I did as you told me and added some debug statements at the beginning and the end of those 2 methods accessing the External variable declared on the DSDT. After some testing I discovered that dropping SSDT-1 (Cpu0Ist) made these to abort before finishing. So right now I am dropping all SSDTs and using only Pike's SSDT + SSDT-1 in the Clover's patched folder.

But I don't know if this was an optimal solution. Maybe I should have dropped Cpu0Ist to avoid conflicts with Pike's SSDT, or copy "what matters" so that I avoid the DSDT methods abortion. Another possibility might be to erase on the DSDT whatever involves that external variable.

What do you think?

Attaching here original SSDT-1 and custom SSDT, just in case.