SSDT generation script (Ivybridge PM)

[PikeRAlpha]

I've tried the script again: ./ssdtPRGen.sh i5-3570K

...

After the warning the script stops, but the file SSDT_PR.dsl is generated and placed on the desktop. I generated SSDT.aml with DSDT Editor, put it in /Extra and rebooted. It works. It seems the only issue now is the warning, but it has no effect on the result apparently. Maybe I did something wrong the first times I tried the script, I don't know. Here is the output of sysctl -a:

Just a harmless reminder that something isn't quite right with your setup, but the SSDT is generated and that is what counts.

 

[JohnonMac]

Just a harmless reminder that something isn't quite right with your setup, but the SSDT is generated and that is what counts.

Right! Thanks for the great script. I do wonder where the warning comes from though. Is it because of the Macmini6,2 definition in combination with the i5-3570K CPU?

 

[PikeRAlpha]

Right! Thanks for the great script. I do wonder where the warning comes from though. Is it because of the Macmini6,2 definition in combination with the i5-3570K CPU?

Thanks. About the warning. This one will be displayed when the SMBIOS data is inconsistent with that what we expect for any given model. In your case Macmini6,2 which happens to use 0x704 for the cpu-type property. Note that this is a simple fix in the config plist of your boot loader.

Update: One more thing. Can you please remove one extra (top) P-State at a time and let us know when you hit the KP? That would be a tremendous help to us. Thanks.

 

[JohnonMac]

Update: One more thing. Can you please remove one extra (top) P-State at a time and let us know when you hit the KP? That would be a tremendous help to us. Thanks.

I know now what caused the KP. When the file SSDT_PR.dsl is generated and I open it with DSDT Editor, I get this error:

Error: Pairs of brackets don't match. Tree not updated.

Looking at the code in DSDT Editor, I saw that the code ended with:

}
[child]

Ok, small error, I thought and changed it into:

}
}

And indeed, it compiled without errors and warnings. I saved the SSDT.aml in /Extra and rebooted. Now the KP occurred. I just opened the SSDT.aml in DSDT Editor and saw that only Scope \_PR_.CPU0 was present, Scope \_PR_.CPU1, Scope \_PR_.CPU2 and Scope \_PR_.CPU3 were missing! That's what caused the KP. I didn't realize something was missing.
Yesterday I did it in a different way. I opened SSDT_PR.dsl in TextEditor, selected and copied all text and pasted it into DSDT Editor. Compiled and saved SSDT.aml and reopened it in DSDT Editor. And indeed now all four Scope \_PR_.CPUx are there. So it was my fault. But it's strange that DSDT Editor sees an error in SSDT_PR.dsl when you open it, while it works fine if you copy and paste the code into DSDT Editor.

 

[toleda]

Right! Thanks for the great script. I do wonder where the warning comes from though. Is it because of the Macmini6,2 definition in combination with the i5-3570K CPU?

Macmini6,1 uses i5 processor and Macmini6,2 uses i7. Unfortunately, MultiBeast 5.2.1/macmini6,1 is actually the 6,2 smbios.plist (bug reported). No error is reported with ./ssdtPRGen.sh i5-3770K and macmini6,2. When a macmini6,1 smbios.plist is avialable, run the script again and no error will be reported. The important point is the SSDT_PR.dsl is the same in both cases and delivers the same performance with either System Definition.

IB System Definitions:
i5 - macmini6,1, imac13,1, macbookpro9,2, macbookpro10,2, macbookair5,1
i7 - macmini6,2, imac13,2, macbookpro9,1, macbookpro10,1

 

[JohnonMac]

Macmini6,1 uses i5 processor and Macmini6,2 uses i7. Unfortunately, MultiBeast/macmini6,1 is actually the 6,2 smbios.plist (bug reported). No error is reported with ./ssdtPRGen.sh i5-3770K and macmini6,2. When a macmini6,1 smbios.plist is avialable, run the script again and no error will be reported. The important point is the SSDT_PR.dsl is the same in both cases and delivers the same performance with either System Definition.

IB System Definitions:
i5 - macmini6,1, imac13,1, macbookpro9,2, macbookpro10,2, macbookair5,1
i7 - macmini6,2, imac13,2, macbookpro9,1, macbookpro10,1

Thanks, will run the script again when a macmini6,1 smbios.plist is available, but indeed the SSDT.aml is working okay.

 

[PikeRAlpha]

@JohnonMac,

The script normally compiles SSDT_PR.dsl for you. That is when it locates iasl, and then it can optionally copy SSDT_PR.aml for you to the right target location (as SSDT.aml) so there is no need for any other tool.

 

[JohnonMac]

@JohnonMac,

The script normally compiles SSDT_PR.dsl for you. That is when it locates iasl, and then it can optionally copy SSDT_PR.aml for you to the right target location (as SSDT.aml) so there is no need for any other tool.

I know, but I don't have iasl, so I have to compile SSDT_PR.dsl manually. I use DSDT Editor for that. Should I download MaciASL?

Update: Ok, I followed my own advice (lol) and downloaded MaciASL, put it on the desktop and ran the script again. But it doesn't work, SSDT_PR.dsl is not automatically compiled, so SSDT.aml is not generated. Not a big problem, I can always manually compile, but I don't know why it doesn't work.

 

[Francis]

I know, but I don't have iasl, so I have to compile SSDT_PR.dsl manually. I use DSDT Editor for that. Should I download MaciASL?

Update: Ok, I followed my own advice (lol) and downloaded MaciASL, put it on the desktop and ran the script again. But it doesn't work, SSDT_PR.dsl is not automatically compiled, so SSDT.aml is not generated and placed in /Extra. Not a big problem, I can always manually compile, but I don't know why it doesn't work.

The function that search for iasl on your system search in /Applications folder.
Copy or Move MaciASL or IASLMe in Applications folder.

 

[JohnonMac]

The function that search for iasl on your system search in /Applications folder.
Copy or Move MaciASL or IASLMe in Applications folder.

Thanks, I just noticed that in the script code. I copied MaciASL to the Applications folder, but it still doesn't work. Then I renamed MaciASL to iasl but that didn't help either. Oh well.