-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core i7-3770K cannot get SpeedStep/PM on 10.8.5 or 10.9.2 (latest scripts) #33
Comments
Running ./ssdtPRGen.sh -w will add the top and bottom P-States, but your CPU it won't use any frequency below 1600 MHz. This was the default for older versions of ssdtPRGen.sh, for OS X versions without xcpm support. The latter made it a little more complicated. Anyway. You are not using XCPM, aka mach_kernel power management, and looking at the filename "ssdt-with-w3-param-yes-working.dsl" -w 3 seems to work so what is the problem? It only works with the HD4000? Not with a discrete GPU? By the way. What Mac model and board-id are you using? |
Hi mate, I apologize for the lack of such info, it was late at night :-) My questions here are not to complain of course, merely to understand and learn some things that, for me, didn't make sense. Using Core i7-3770K on Gigabyte GA-Z77N-WIFI (not-overclocked) set as Macmini6,2 with board ID Mac-F65AE981FFA204ED. Apparently, also iMac13,1 (with Mac-00BE6ED71E35EB86) is compatible but I read everywhere that Macmini6,2 has better results for this CPU. Indeed with -w 3 flag, the resulting SSDT works properly, so my question was why adding this workaround top/bottom in code works? The OS needs these values to be present, even if never achieved? e.g. 800MHz for CPU! Especially the top one at 3901MHz is an interesting entry. But when generating SSDT without flags, as I mentioned, and if DropSSDT=Yes then the desktop loads at fixed 800MHz which wasn't expected behavior... I have an update: The only thing I get is an error in Mavericks about unknown CPU ID, I guess expected, right? What is your advice? DropSSDT=Yes and using a normal SSDT (no workarounds) with XCPM flag in kernel? (to introduce that "plugin-type" part in the code?) I re-generated SSDT with the script v13.5 now and getting same output with either plain or W=3 flag, as your script seems to properly detect XCPM and ignoring the flag:
(sorry I tried to find the [code] tag but don't know how, I made them as quoted) and the one generated with -w 3 is here, for your reference:
|
Use this script https://github.com/Piker-Alpha/debugMachKernel.sh |
Thanks for your input, will do ASAP. Just to update you:
If booting without SSDT.aml and DropSSDT=No but using only -xcpm flag, all is perfect except the warning of the CPU ID not being recognized. |
Let's stick to one power management feature at a time. Preferable the non-xcpm one so please remove the -xcpm flag (for now) and without this flag you are using the AppleIntelCPUPowerManagement.kext which used to work with Sandy Bridge and Ivy Bridge processors. I also need to know if you are using a patched version of the kext, or that you are using the factory/original one. Which in my opinion is preferred. In short. Run ./ssdtPRGen.sh -w 3 -x 0 and reboot without the -xcpm flag. p.s. Please. Do not change your SMBIOS data, because that adds complexity. Something I don't have time for right now. |
OK mate, did as requested. Nothing is patched at all, especially AppleIntelCPUPowerManagement.kext is vanilla. Also, always using Macmini6,2 as I also don't expect to experiment with smbios.plist as you said. With latest script v13.5, compiled -w 3 -x 0 and rebooted without -xcpm, but with DropSSDT=Yes. It works as expected, Turbo goes to 3.90GHz and GeekBench produces similar results (10.8.5). The AppleIntelCPUPowerManagement.kext is loaded when checking the kexts on Terminal. I get these messages to Console (with "kernel" filter):
Minimum CPU is 1600MHz and maximum (Turbo) is properly reaching 3900MHz. Now, if I replace SSDT.aml without changing anything else at all, with the one NOT including the bug fix and those added workarounds for Ivy Bridge, the OS boots and clock is locked at 800MHz which is totally wrong. Can't even imagine why it goes to 800MHz to begin with :-) Even GeekBench that's pushing CPUs isn't changing the clocks (verified via Intel Power Gadget too). Console errors same as above. The AppleIntelCPUPowerManagement.kext is loaded when checking the kexts on Terminal. Weird! |
The only two items that jump out are: "AppleIntelCPUPowerManagement: Turbo Ratios 4444" "X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0" |
Hi mate, in the org.chameleon.Boot file, the "SystemType" key is of course 1 for desktop (Mac Mini). The BIOS was reverted to "Optimized Defaults" and the Frequency screen/tab shows no setting for Turbo states, to be honest. I read on TonyMacX86 forums that with default BIOS settings this board works fine. Please remember it's Core i7-3770K the K-variant… There's a BIOS page for setting "Advanced CPU Core features". It has Turbo Ratio 39 for 1 active core, 39 for 2 cores, 38 for 3 cores, 37 for 4 active cores but all set to "Auto". Should I change that to forced values? OK just did -- rebooted with forced (same) values instead of auto-setting. Other CPU parameters are now "Enabled" instead of "Auto". Now I get "Turbo Ratios 2344" in boot log. GeekBench shows lower results now (as 4 cores go to max. 3700MHz obviously). Not good... Nevertheless, I am still getting that other errors :-(
NOTE: Obviously with the -xcpm there is no "Turbo Ratios" entry in Console from AppleIntelCPUPowerManagement, as I checked in earlier boot-logs, nor the X86PlatformPlugin errors. |
Sure. Use whatever turbo settings you want, but that's not how Apple is setting them. Anyway. You said: "When using the -xcpm flag in booting, with the newly created SSDT.aml (without the bug/workaround) and DropSSDT=Yes, I am getting many errors on both 10.8.5 and 10.9.3" But now you say there are no X86PlatformPlugin errors with -xcpm in com.apple.Boot.plist? Surely you understand the confusion here? Update: Now you can add -xcpm under "Kernel Flags" and run: ./ssdtPRGen.sh -x 1 to see what that brings. |
Hi Pike, thank you again for spending time to investigate this issue. Sorry if it was not clear. Allow me to explain the 3 scenarios (with vanilla kexts, same SMBIOS etc.):
Let me know if it's useful to create a text file with the 3 different kernel logs, I'd like to ease your life as much as possible :-) EDIT: Missed your update, will check and report back. Many many thanks again. |
Loading with only -xcpm and without SSDT.aml at all, running ssdtPRGen.sh -x 1 produces the following:
Text-comparing the resulting SSDT.DSL with previously generated, shows no difference at all with the "cleaner" SSDT i.e. no workarounds inside, nor any value changes in C/P-Steps… I have compiled the log for 4 scenarios, here:
Logs uploaded here, many thanks: http://pastebin.com/YtJBhXVX |
a. First try -x 1 only. b. If -x doesn't work then try -w N -x 0 (where N is 1, or 2). c. If that still doesn't work then use -w 3 -x 0 and remove these:
Now fix the package length from 0x21 to 0x1D and change Name (APLF, 0x08) to Name (APLF, 0x04) Compile and reboot and report back (thanks). |
OK here are my results (on 10.8.5 as it's my first boot partition):
a) generated with -x 1 only: still getting errors:
b) generated with -w 1 -x 0: Same errors as a) c) generated with -w 2 -x 0: only stepper; no error on PStates found.
d) Generated with -w 3 -x 0 and removed bottom 4 entries, fixed APLF and recompiled: Same errors as a) except the value:
What does APLF value reflect? NOTE: I am totally ignoring the errors below, didn't expect you to say they appear on real Macs!
I hope I gave you a better idea? Many thanks, mate. |
I have to be quick so the only thing I need to know is if -w 3 -x 0 worked or not.
APLF should point to the lowest possible frequency for your CPU (1600 MHz) |
Hello again PikerAlpha, sorry for my absence, too busy at work and not time to experiment and fix. Anyway, I formatted and re-installed 10.9.3; I must have rebooted 100 times (thank God for SSD) and I've been battling all this time to make Clover work (readying myself for Yosemite) but I am getting different SSDT results to Chameleon! With BIOS defaults (i.e. CPU Core features as Auto), i7-3770K, OS X 10.9.3 now and MacMini6,2 and DropSSDT=Yes: a) Chameleon without -xcmp
Values -w1 or -w2 with -x0 produces the known 800MHz lock. So no point investigating further. Same stands for using your script without any parameters, system locks at 800MHz. b) Chameleon with -xcmp but DropSSDT=No
Using the DSDT fix in CPU0 that you suggested, produces unexpected errors. Is it because of the CPU model? Anything to tell the system it's a compatible i7-3770 CPU? There's no XCPM registered line:
Back to working DSDT without the CPU0 fix, obviously. c) Chameleon with -xcmp and DropSSDT=Yes now: Value -w 3 -x 1 curiously produces errors:
Value -w 2 -x 1 produces less:
Value -w 1 -x 1 produces:
Suggestions? Modify the Mac hardware profile as you wrote?
Many thanks, hope you have a clearer picture now… that was a log of debugging ;-) UPDATE: Saw also your post (http://www.tonymacx86.com/mountain-lion-desktop-support/86807-ml-native-ivy-bridge-cpu-gpu-power-management.html) and replaced Mac-F65AE981FFA204ED.plist with the ones for MacBookPro10,1 etc. and can't shake off that "Failed to send stepper" error :-( Also, changing SMBIOS to Mac13,2 that has i7-3770 CPU, causes kernel panics (SSDT not dropped and with -xcpm as flag). Without -xcpm, it boots but no Turbo mode and still unknown CPU error... |
This "X86PlatformShim::start - Failed to send stepper" can be stopped by adding a boot argument (-xcpm_ignore_fv). Thanks to techblowfish for the friendly reminder. |
@mackonsti I have the same CPU as you, just a different motherboard. I must say that the errors you are getting are far in excess of those i came across when setting up my system. My incline is that these errors maybe related to Chameleon/Chimera and perhaps whatever version you may be running. I do not think that Piker's script is the one causing all these errors but I could be wrong. I'd advise you setup a pure UEFI environment in your BIOS and using Clover. I believe this way we can welter down these logs to focus on the important ones. |
Hello to both of you, Piker, Techblowfish, thanks for your help. As I mentioned earlier to Piker, Clover has a very different behaviour to Chameleon. Using both latest versions. As I am trying to iron out issues, I used Chameleon that I know well; was battling Clover until recently. Allow me to come back to you this weekend with findings on Clover and Core i7-3770K. It's not Piker's script most likely, just that I am doing all reboots with different scenarios, so I can help Piker too, in his excellent work. Thanks again. @techblowfish do you use a similar mainboard, with same Z77 chipset or H77? @Piker-Alpha do you think that -using xcpm_ignore_fv flag, will kill the error but still Speedstepping will work properly? You seem to have investigated the kernel, recently, hence my question. Should I use that special kext you have on your blog, to check the P/C states debug output? |
I use a ASUS P8Z77-v pro. I would advise you to use a DSDT and an SSDT with Clover. If you need to have a look at my config.plist i can post it here. My system worked fine even with that error. This is because the IvyBridge CPUs do not use frequency vectors anyway. The (-xcpm_ignore_fv) flag explicitly informs the Kernel not to try to load any frequency vectors from a file. |
Hello guys, here are my results. Mavericks 10.9.3 with Clover_v2k_2703 installed on external USB stick. Settings Gigabyte GA-Z77N-WIFI:
Settings in Clover:
I get in boot log with Turbo working (up to 3.9GHz) and Geekbench (x64) at 14810:
Interesting fact: Even if I don't have DropOem checked, I have an SSDT.aml in the "patched" directory hence the lack of the errors below (which means it's been read):
Adding your extra flag i.e. -v darkwake=0 -xcpm -xcpm_ignore_fv results to same "failed to send to stepper" error being present. It's not clear to me if we include both or either xcpm flags :-) If I remove -xcpm completely, the boot process freezes and I can't get to desktop (running verbose boot at the moment). I think it freezes before the part where the OS tries to determine CPU power management etc. and USB devices freeze too. Any ideas/suggestions why? Could it be Clover? With -xcpm removed from kernel flags, even setting DropOem=Yes and having an SSDT.aml in "ACPI/patched" still can't boot… it's crazy. Changed to iMac13,2 but same result. @techblowfish can you please share your Clover config.plist in a site like pastebin.com? Do you use simple/secure UEFI boot in BIOS? Perhaps also share your SSDT too? UPDATE: using both -xcpm and -xcpm_ignore_fv causes a new error to appear:
Can you confirm it, guys? |
Here is my config.plist Please try not use XMP until you have a stable system. So just load optimised defaults like you have done. Also, why not try to install clover on the same hard drive as your OS. Backup first please. |
Thank you @techblowfish for your Clover config.plist, I was able to get my system to a stabler Clover booting condition, but I still get the "stepper" error:
And of course, booting without -xcpm is not working as the system just stops in verbose (I don't have desktop, but seems system loads, can access via SSH from another Mac). I am not aware of any other Clover parameter that will allow to boot without -xcpm? Like dart=0? Also, I used your DropTables parameters, too, and the SSDT.aml with only the -w 2 parameter fixes (i.e. lower P-State values injected). Boot flags -xcpm and -xcpm_ignore_fv didn't change anything with respect to the "stepper" error, and disabling CPU features in BIOS as you posted on Piker's blog, didn't help either. Any comment @Piker-Alpha on these two simultaneous flags? |
It seems that your system needs to use a patched kernel in order to be able to use the "-xcpm" and "xcpm_ignore_fv" flags. This is why you are getting kernel panic. So you can try this: I have used the Perl script 10.9.1 for 10.9.3 and it works. |
Hi @techblowfish thank you for your tip, but why would I need to patch the setup/kernel since it does detect -xcmp flag. Just not the other one. So can we use both or either? Still declaring Macmini6,2 and running 10.9.3. Removed GFX0 (NVidia GeForce GT 610) and used DSDT for Intel HD Graphics (as there are 2 SystemMemory settings in DSDT that crash computer if not changed). Anyway, for testing, I did patch the kernel and to be honest, the error is still there. Patched, cleared kextcache, rebooted: a) Flag -xcpm still has "Failed to send stepper" error. With patched kernel, which SSDT do you use? With fixes or plain? If you're interested, here is my Clover config.plist which doesn't have anything weird set-up: https://dl.dropboxusercontent.com/u/10966941/config.plist @Piker-Alpha: I am giving up, so please, can you kindly comment what the error's impact is on the system? I can only boot without -xcpm with NVidia card removed, hence using the previous AppleIntelCPUManagement kext. But Yosemite is bound to use -xcpm, I think... |
Hi @mackonsti, the "-xcpm_ignore_fv" does not really have any bearing on how your system work. This is because your CPU is not a Haswell anyway so whether you use it or not should not cause a kernel panic. I would suggest for you not to use this flag for the time being and focus on getting your SSDT right with Pike's script. |
Hello PikeRAlpha, many thanks for your continuing work on this script! I am using a Core i7-3700K on a Gigabyte GA-Z77N-WIFI not over-clocked but setup normally.
When I started experimenting with your script v9.1, the resulting SSDT seems to have worked on both 10.8.5 and 10.9.2 I think. But since script v12.x and until today v13.5 the normal script produces SSDT that freezes the clock at 800MHz whilst the reading is supposed to start at 1600MHz. Normal top speed is 3500MHz and turbo goes to 3900MHz.
a) Running the hackintosh without PEGP discrete graphics card, did this affect the results/output? Original SSDT generation via your script was with a borrowed NVIDIA card…
b) I read in another reply you wrote that Apple changed something and we must test -w 2 if -w 3 doesn't work as older scripts added top/bottom entries. But in my case for the Core i7-3770K it's the other way around :-) (#29) Should I still try the -xcpm flag in /Library/Preferences/SystemConfiguration/com.apple.Boot.plist ?
c) Comparing the resulting DSL files, and examining them, I see the "workaround" that adds 3901MHz (0x0F3D) entry on the top of the APSS entry:
I have no idea what this does, but it seems that it's needed. However, there are more entries entered BELOW the 1600MHz barrier, namely:
…which I suspect has to do with the IGPU, right? The official lowest CPU frequency is supposed to be 1600MHz but if these bottom APSS part(s) are missing, the Desktop boots at 800MHz clock, making the computer too slow :-)
I am attaching here all 3 files for your text-comparison:
a) generation without any parameters
b) generation with -w 2 parameter
c) generation with -w 3 parameter (which enables SpeedStepping whilst using HD4000)
Your comment please? If I plug back a discrete graphics card, would I make this work without the -w 3 or -w 2 option, you think?
Many thanks in advance for your time and kind help. Please let me know if you need scripts outputs?
P.S. Files cannot be uploaded, instead packing them in a separate web-folder:
http://fzr3lbkikh.1fichier.com/
The text was updated successfully, but these errors were encountered: