A new version of ssdtPRGen (v13.1) is now available from my Github repository. It should just work, and combat the dreaded “Warning: No ACPI Processor declarations found in the DSDT!” but since I don’t have any time to conduct testing myself – this is where you come in handy – and I also don’t have all sorts of different configurations to test the script with so you are warned.
Changelog
– enhanced _debugPrint with argument support.
– Haswell refresh (desktop) processor data added.
– triple/quad byte package length support added.
– typo in help text (-turbo) fixed.
– opcode error (‘Name’ instead of ‘Device’) fixed.
Please report bugs and other oddities over at: https://github.com/Piker-Alpha/ssdtPRGen.sh/issues
Thank you for testing this update!
Pike's Universum 
Hello Pike, I’ll give the script a shot in a second, but I have a question that was never clear for me in any instructions. If I am overclocking a haswell, do I run your script with the -turbo parameter or the -frequency one with my OC mhz? If It goes to turbo, and If I am ocing my unclock as well (ring multiplier to some) would that then go to -frequency?
Thanks a lot for all the work
Use -turbo for OC frequencies, but I would not change ring frequencies.
Piker thanks so much for all the effort!
I have an annoying problem, if I look at the output I get:
Scope (_PR_) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a ‘MacPro6,1’ with board-id [Mac-F60DEB81FF30ACF6]
Haswell Core i7-4770K processor [0x306C3] setup [0x0705]
With a maximum TDP of 84 Watt, as specified by Intel
Number logical CPU’s: 8 (Core Frequency: 3500 MHz)
Number of Turbo States: 4 (3600-3900 MHz)
Number of P-States: 32 (800-3900 MHz)
Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C3,C6)
Warning: ‘system-type’ may be set improperly (1 instead of 3)
So to me, besides the Warning ‘system-type’, everything looks to be okey.
But after I boot and check MSRDumper I only get the following P-States:
kernel[0]: MSRDumper PStatesReached: 8 35 36 37 38 39
Any thoughts?
Btw I’m using clover as UEFI bootloader.
Regards,
Simania
Did you copy the FrequencyVectors data from one of the other Mac-*.plist in /S*/L*/E*/IOPlatformPluginFamily.kext/C*/P*/X86PlatformPlugin.kext/C*/Resources to that of Mac-F60DEB81FF30ACF6.plist?
Evening Piker,
Sorry for my late reply, but as you’re sanding your room, I’m sanding my boat, takes ages……
To answer your question, I’ve not, should I?
Regards,
Simania
Yes. XCPM works with FrequencyVectors for Haswell processors. Adding the missing data is as simple as running a new script I wrote, which is available from my Github repository at: https://github.com/Piker-Alpha/freqVectorsEdit.sh
I am getting “Unknown Processor Model” suddenly with my E5-2695 V2 and 2697 V2.
Oops. I recently changed some lines in function _getCPUNumberFromBrandString. What do you get from:
echo 0x$(echo “obase=16; `sysctl machdep.cpu.model | sed -e ‘s/^machdep.cpu.model: //’`” | bc)
Also. Are you using the -c argument? If not give that a try.
Thanks for your quick reply! Here is what I get when I attempt to run that command:
1.
MacPro:~ MacPro$ sudo echo 0x$(echo “obase=16; `sysctl machdep.cpu.model | sed -e ‘s/^machdep.cpu.model: //’`” | bc)
sed: 1: “‘s/^machdep.cpu.model:
“: invalid command code ?
-bash: ”: command not found
0x“obase=16
2.
Also, this is an ES version of the CPU if it matters, but I was able to use ssdtPRGen without i incident up until quite recently.
3.
Using: sudo ./ssdtPRgen.sh -c 1:
Override value: (-c) CPU type, now using: Ivy Bridge!
System information: Mac OS X 10.9.2 (13C64)
Brandstring ‘Genuine Intel(R) CPU E2697V @ 2.70GHz’
Error: Unknown processor model …
Aborting …
Done
4.
Trying to use -p ‘e5-2697 v2’ results in the same error.
5.
Next, I ran: sudo sysctl -a | grep ‘^machdep\.cpu’
machdep.cpu.max_basic: 13
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Genuine Intel(R) CPU E2697V @ 2.70GHz
machdep.cpu.family: 6
machdep.cpu.model: 62
machdep.cpu.extmodel: 3
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 4
machdep.cpu.feature_bits: 3219913727 2143216639
machdep.cpu.leaf7_feature_bits: 641
machdep.cpu.extfeature_bits: 739248384 1
machdep.cpu.signature: 198372
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: SMEP ENFSTRG RDWRFSGS
machdep.cpu.extfeatures: SYSCALL XD 1GBPAGE EM64T LAHF RDTSCP TSCI
machdep.cpu.logical_per_package: 32
machdep.cpu.cores_per_package: 16
machdep.cpu.microcode_version: 1046
machdep.cpu.processor_flag: 0
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 4384
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 0
machdep.cpu.thermal.invariant_APIC_timer: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 1
machdep.cpu.thermal.fine_grain_clock_mod: 1
machdep.cpu.thermal.package_thermal_intr: 1
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.energy_policy: 1
machdep.cpu.xsave.extended_state: 7 832 832 0
machdep.cpu.arch_perf.version: 3
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 8
machdep.cpu.cache.size: 256
machdep.cpu.tlb.inst.small: 64
machdep.cpu.tlb.inst.large: 8
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.shared: 512
machdep.cpu.address_bits.physical: 46
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 12
machdep.cpu.thread_count: 24
The CPU brandstring (“Genuine Intel(R) CPU E2697V @ 2.70GHz”) of your ES is broken. You need to use: ./ssdtPRGen.sh -p ‘E5-2697 v2’ (case sensitive).
Working with the -p specification. Thanks! Sorry, did not realize it was case sensitive.
Same error v12.7 as well. Went back to v9.1 and it generates again but there seem to be a few differences.
Perhaps this is because I have an ES CPU? Does anyone have a retail Xeon V2 that can generate with 12.7+?
Hi Pike
My system def. is iMac 13.1 and this specs : i5-3570K,AsrockZ77Pro3 with patched bios.
I tried your script ssdtPRGen.sh v13.1 -w3 and i got this in the console :
XCPM: registered
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x13)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x13
I tried system def. Mac mini 6.1 and 6.2 but the same problem,i am using clover,i got 6 speed steeps: AICPUPMI: CPU P-States [ 16 25 29 34 38 42 ]
How i can fix the problem?
If you use a SSDT generated with help of ssdtPRGen.sh then don’t let Clover inject C/P-States and use: ./ssdtPRGen.sh -w 1
See also ./ssdtPRGen.sh -h
@pikeralpha:
I’m using chameleon bootloader.
Which command us on terminal for ssdtPRGen.sh.
How to use him?
I have Mac Pro6,1 Ivy Bridge 3770k GA-Z77X-UD3H
Please help….
Thank in advance!!!
whether it helps in terminal:
1.curl -o ssdtPRGen.sh https://raw.github.com/Piker-Alpha/RevoBoot/clang/i386/libsaio/acpi/Tools/ssdtPRGen.sh
2.chmod +x ssdtPRGen.sh
3../ssdtPRGen.sh
Thank you for the reminder. README file added with proper instructions.
I tested my SSDT on 10.9.3.I create my SSDT via ssdtPRGen.sh 13.4 and work perfect.On MSRDump test my P-State 16,25,30,35,37,38,39.
Hello pikeralpha!
I used your script but I’m only receiving three P-States: 8, 34, 48.
I have a Haswell i5-4670K, MacPro6,1 SMBIOS with frequency vectors from iMac 14,3.
What could it be?
Thank you very much!
Sorry, it’s 8, 34, 38*
Power management for iMac’s is restricted by Apple so it is better to use the frequency vectors of the MacBookPro11,3
Much better now!
kernel[0]: MSRDumper CoreMulti(17)
kernel[0]: MSRDumper PStatesReached: 8 17 34 35 36 37 38
kernel[0]: MSRDumper CoreMulti(8)
kernel[0]: MSRDumper PStatesReached: 8 17 34 35 36 37 38
kernel[0]: MSRDumper CoreMulti(17)
kernel[0]: MSRDumper PStatesReached: 8 17 34 35 36 37 38
Two doubts…
1. MSRDumper shows that most of the time the multiplier is in 17 rather than 8 while system is “idle”. Is that normal/expected?
2. Should I get even more PStates, meaning that I still have things to configure correctly?
Thanks again!!