Jump to content



Member Since 04 Aug 2005
Offline Last Active Apr 06 2014 12:52 AM

Topics I've Started

Chameleon won't load modules?

27 January 2014 - 02:34 AM

I have a latest r2345 of chameleon installed and prior to that I had a r2286, neither of which load modules from the /Extra/modules/ folder.


I've placed the latest FileNVRAM.dylib into the modules/ folder it does not load. I wrote my own module as a test and that does not load either.


Any help would be appreciated.




Fix: Failed to get max non-turbo PState. Set max non-turbo PState to default value 1

13 January 2014 - 01:43 AM

If you are getting a message:


X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1


in your kernel log, add the following to your SSDT's CPU0 scope:


Name (APSN, 0x0N)


Where N > 0. To find N, look at your _PSS (NPSS, APSS) table and count from index 0 (top) till you reach it.


For example in my case, I only have one turbo state so the next highest non-Turbo would be 1:




Testers needed: CPU Power Management for SB and IB Xeon(s) or i7-39xx on X79 or C60x ch...

10 January 2014 - 04:12 AM

This post was last edited on Feb. 23, 2014 at 15:00:00 EST, reason: Posted a link to MSRpatcher.dylib v007 - please read the note next to it



I'm looking for fellow users who have SB or IB Xeon(s) or i7-39xx, on X79/C60x motherboards and lack CPU Power Management, to test this hack.


This is an advanced topic and I will assume you have tried everything else and got everything else working, but are stuck with NullCPUPowerManagement.kext and two power states (min/max).


This means:


- you have Xeon-E5 v1 (SB), Xeon-E5 v2 (IB), i7-39xx or i7-49xx (the last two have the same core as Xeon counterparts, just higher clock and no MP support)


- you have cpu-type set to 0xa01 (2561) and are using MacPro6,1 in SMBIOS it appears to work better for some people as Macmini or iMac than MacPro as a platform definition,


- you have plugin-type = 0x01 set on the CPU0, to utilize X86Platform* (we might deal with ACPI_SMC_PlatformPlugin later) you are using either X86Platform or ACPI_SMC_Platform,


- when you run with AppleIntelCPUPowerManagement.kext you get "Unknown CPU: family = 0x.. , model = 0x.. , stepping = 0x.." from AICPM in kernel log at the very top before AppleACPICPU is initialized (this has nothing to do with About This Mac Unknown cpu),


- your C- and P- states are properly initialized in the registry (your SSDT is enabled and working) and are not getting any errors from X86Platform* during boot,


- you do NOT have MSR register 0xE2 bit 15 set, or you have hacked your BIOS to enable it (patched AICPM is NOT acceptable, we need a working 0xE2 MSR),


- you are running 10.9.2 build 13C32 you are running 10.9+ (normal mode, not safe mode),





The tool we will use to monitor things is PikeRAlpha's AppleIntelCPUPowerManagementInfo.kext, so get that from his blog, or better yet compile from github (https://github.com/P...-Alpha/RevoBoot).


So, if you are ready to test, below is a AppleInteCPUPowerManagement binary, patched to identify your Unknown CPU as SB or IB. Replace (backup first) the original one from SLE/AICPM with the appropriate one for your cpu. Make sure that permissions are correct, and if necessary touch /S/L/E to re-cache the extensions folder.


Obviously, remove any AICPM disabler kexts first (NullCPUPowerManagement.kext, etc.)


Boot into the OS X with following flags: -v debug=0x144 msgbuf=131072


You should see your turbo modes initialized around the top of the kernel log as well as no other errors except this one: X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1.


Hopefully you won't get a KP, but if you do, record where it KPs. Once system is up, load Pike's AICPMI and take a look at the output, let your system run for a bit use it as usual, then check dmesg a fee times, it should fill with some C and P states.


Also, I'm including a patched kernel to allow for full debug output if you need it. It is very "chattery" so expect lots of text, thus boot with: mach_kernel.dbg -v -cpuid debug=0x144 msgbuf=131072


This is all preliminary work so if it does not work, well that's why we are testing...post your AICPMI output for discussion and if necessary any other kernel log related items


Please post your CPU model and Platform (MacProX,Y; MacminiX,Y; iMacX,Y) when posting your logs so we have a bit more information.






To get even more debugging output, boot with the following arguments:


debug=0x144 msgbuf=309212 ioppf=0xff acpi_layer=0x08 acpi_level=0x02


You will see tons of output from X86Platform* which will tell you much about your setup and whether it can parse the SSDT properly or not. Follow through with any errors and correct them, then see what happens when you load AICPMI again.


Here's what I get in my kernel log (related entries only):



-- If you are getting a message in your kernel log:


X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1


Add the following to your SSDT's CPU0 scope:


Name (APSN, 0x0N)


Where N > 0. To find N, look at your APSS method (aliased SPSS table) and count from index 0 (top) till you reach it.


For example in my case, I only have four (index position 0-3) turbo state so the next highest non-Turbo index position would be 4:




-- If you are not sure about your C-state declarations in SSDT (or even if you are), please use the one below - regardless of whether you think you have made it right, or you let Pike's script generate it for you.


This also contains debug entries that you will see pop up in your kernel log if you have ACPI and AICPM debugging on. I don't have to tell you how to use this, do I? :)


Sigh, ok...CPU0 scope contains the original as is, all other CPU scopes have aliases pointing to CPU0 scope, similar to this (adjust to your config don't copy/paste):


Method (_CST, 0, NotSerialized) { Return (\_SB.CP00._CST) }

Method (ACST, 0, NotSerialized) { Return (\_SB.CP00.ACST) }





-- If you are concerned that you are not getting lower P-states, presently I believe they will not be reached because OS X seems busy all the time. Instead of P-states I suggest looking at the HWMonitor's Core Package Watt use as that might be a better indication of your current state. If you google about detecting SpeedStep in OS X you will see that it is not that easy to get an accurate reading.


You might have some luck getting an accurate reading using an Intel® Power Gadget 3.0 for Mac, but it only works on uniprocessor systems. :(


Here's an AICPMI output from my MBP running 10.8.4 after taxing the CPU then sitting idle for 15 mins, just for {censored} and giggles:





-- If you want to see my IOreg and AICPMI, here they are:


View of my C-States in IOJones




View of my P-States in IOJones




You should have something similar, adjusted for the number of CPUs, cores and threads, of course. If not then your basic SSDT setup is not correct and needs to be fixed. That is really beyond the subject of our discussion here.


Here is my AICPMI output after running Geekbench...still missing the lower P-States.





-- If you are adamant about not patching your BIOS, you may try patching the MSR 0xE2 to avoid the KP in the AICPM, using the following line:


sudo perl -pi -e "s|\xE2\x00\x00\x00\x0F\x30|\xE2\x00\x00\x00\x90\x90|g" /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement


But don't come to me if this hack or speedstep does not work as intended.






Original AppleIntelCPUPowerManagement (13C32): http://www.putlocker...D46F6514CAB046B - Ivy Bridge Xeon owners, use this without patching


Patched AppleIntelCPUPowerManagement v003 (SB+IB): http://www.putlocker...F9CFD5146AA3569


Patched kernel 10.9.2 13c32 for debug: http://www.putlocker...BA697D801E0DE4D


Chameleon module to set some MSRs:

MSRpatcher.dylib v002:  http://www.mirrorcre...files/0XEEDZGJ/  - use this if you have 0x1N00040N value in your MSR 0xE2,

MSRpatcher.dylib v007: http://www.mirrorcre...files/0RNKQMMN/ - use this if you have 0x40N value in your MSR 0xE2, also displays values that it sets.


MSRpatcher will change the value of your MSR 0xE2, IF IT'S NOT LOCKED, by forcefully enabling C3/C6/(C7 if supported) states, as well as set some default values to MSR_PKGCx_IRTL registers.

Because this is running from your boot loader, it could potentially hang your system. I suggest you use a USB stick with Chameleon installed on it, put this module there and boot from it instead.


© 2017 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy