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

[omni]

Hi Pike,

 

Something appears to be off with the Xeon based hacks, which does not happen on normal Core ones.

 

AICPMI reports P-States quite well for Core CPUs, IB and SB alike, whether they use XCPM or AICPM. But when it comes to Xeon, then we either get low/high (with NullCPUPM) and no turbo, or just a single low or high P-state without NullCPUPM.

 

As you've noted, couple of people on your blog who write to MSR Cx_IRT registers from the boot loader do get a few turbo states, although we are not sure whether they have standard performance states along.

 

Reason for a binary patch is that Xeon based CPUs (at least SB ones) are not being detected, as I've explained in my emails to you. They simple end up being registered as NullCPU and that infamous Unknown CPU message comes up. Since there's no PM for NullCPU in AICPM, nothing happens and we are back to square one.

 

If you have an alternative option to binary patching to get SB and IB Xeons detected and initialized, by all means please tell us.

EDIT: We really need to see AICPMI from a real MacPro6,1 as well ... anyone?

 

 

[frankiee]

Seems like I have now finally success on my side!

 

A BIG thanks go out to Omni for his patch and also Balamut for providing the correct SSDT for 4930K.  With this one, my power gadget output looks like this:

 

 

 

 

Now, does that look OK? At least no problem now with reaching states from x12 up to x39.

 

So yes it is pretty clear that Pike's script is just wrong with 4930K - also a bit sad since he insisted on his blog that it works - which it does clearly not. And I thought it was my error. Sigh.

 

Also the PMInfo kext provided by Balamut does not crash in contrast to Pikes one, so here is the output:

19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MWAIT C-States.....................: 4384
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_CORE_THREAD_COUNT......(0x35)  : 0x6000C
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PLATFORM_INFO..........(0xCE)  : 0xC10F0012200
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PMG_CST_CONFIG_CONTROL.(0xE2)  : 0x403
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PMG_IO_CAPTURE_BASE....(0xE4)  : 0x10414
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_MPERF.................(0xE7)  : 0x26BDD7AE6F
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_APERF.................(0xE8)  : 0x2534270856
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_FLEX_RATIO.............(0x194) : 0xE0000
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_IA32_PERF_STATUS.......(0x198) : 0x23DE00002400
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_IA32_PERF_CONTROL......(0x199) : 0x2400
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_CLOCK_MODULATION......(0x19A) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_THERM_STATUS..........(0x19C) : 0x88380000
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_MISC_ENABLES..........(0x1A0) : 0x850089
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_MISC_PWR_MGMT..........(0x1AA) : 0x400001
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_TURBO_RATIO_LIMIT......(0x1AD) : 0x2424242425252527
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: IA32_ENERGY_PERF_BIAS......(0x1B0) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_POWER_CTL..............(0x1FC) : 0x2104005B
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_RAPL_POWER_UNIT........(0x606) : 0xA1003
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKG_POWER_LIMIT........(0x610) : 0x69F40005A9F40
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKG_ENERGY_STATUS......(0x611) : 0x1952BF36
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKGC3_IRTL.............(0x60a) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKGC6_IRTL.............(0x60b) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PP0_CURRENT_CONFIG.....(0x601) : 0x14149480001FFF
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PP0_POWER_LIMIT........(0x638) : 0x80000000
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PP0_ENERGY_STATUS......(0x639) : 0xC849A23
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PP0_POLICY.............(0x63a) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKG_C2_RESIDENCY.......(0x60d) : 0x5F66A802E4
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x0
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x6A16874062
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: Low Frequency Mode.................: 1200 MHz
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: Clock Speed (Max. Non-Turbo Freq.).: 3400 MHz
19/01/14 17:47:56,000 kernel[0]: AICPUPMI: Maximum Turbo Frequency............: 3900 MHz
19/01/14 17:47:57,000 kernel[0]: AICPUPMI: CPU P-States [ (12) 36 ]
19/01/14 17:47:57,000 kernel[0]: AICPUPMI: CPU C3-Cores [ 0 2 4 5 ]
19/01/14 17:47:57,000 kernel[0]: AICPUPMI: CPU C6-Cores [ 0 4 6 7 8 9 11 ]
19/01/14 17:47:58,000 kernel[0]: AICPUPMI: CPU P-States [ 12 36 (37) ]
19/01/14 17:47:58,000 kernel[0]: AICPUPMI: CPU C3-Cores [ 0 1 2 4 5 6 7 8 9 ]
19/01/14 17:47:58,000 kernel[0]: AICPUPMI: CPU C6-Cores [ 0 1 2 3 4 6 7 8 9 10 11 ]
19/01/14 17:47:58,000 kernel[0]: AICPUPMI: CPU P-States [ 12 (34) 36 37 ]
19/01/14 17:47:58,000 kernel[0]: AICPUPMI: CPU C6-Cores [ 0 1 2 3 4 5 6 7 8 9 10 11 ]
19/01/14 17:48:00,000 kernel[0]: AICPUPMI: CPU C3-Cores [ 0 1 2 3 4 5 6 7 8 9 ]
19/01/14 17:49:08,000 kernel[0]: AICPUPMI: CPU P-States [ 12 34 36 37 (39) ]

Also got MSR_PKG_C3_RESIDENCY at "0". Hmm, must this still be fixed or can be ignored? Also I do not see P-States generated under x34, but that could also just be a bug in the info kext. At least guessing from Power Gadget, the CPU seems to have no problems reaching every state in between. Using clover as my bootloader.

 

So what do you think? Is this it?

[Pike R. Alpha]

Hi Pike,

 

Something appears to be off with the Xeon based hacks, which does not happen on normal Core ones.

 

AICPMI reports P-States quite well for Core CPUs, IB and SB alike, whether they use XCPM or AICPM. But when it comes to Xeon, then we either get low/high (with NullCPUPM) and no turbo, or just a single low or high P-state without NullCPUPM.

 

As you've noted, couple of people on your blog who write to MSR Cx_IRT registers from the boot loader do get a few turbo states, although we are not sure whether they have standard performance states along.

 

Reason for a binary patch is that Xeon based CPUs (at least SB ones) are not being detected, as I've explained in my emails to you. They simple end up being registered as NullCPU and that infamous Unknown CPU message comes up. Since there's no PM for NullCPU in AICPM, nothing happens and we are back to square one.

 

If you have an alternative option to binary patching to get SB and IB Xeons detected and initialized, by all means please tell us.

EDIT: We really need to see AICPMI from a real MacPro6,1 as well ... anyone?

Well. It would be nice for a starter when people could make up their minds when it comes to what P-States they want to see. For me it is easy to show all P-States, but those won't be triggered by Apple's power management, and we've all been trying to get AICPUPMI to report the correct data. In terms of Apple that is.

 

I am well aware about the Cx_IRT's, since it was me who suggested it to initialise them properly, after I found out that Apple is using these values. It may be wise to match your data in the ACPI table (SSDT) with what you have in the MSR's. Unfortunately not all BIOS vendors initialise them properly, but then the data from BITS comes in handy.

 

But didn't people report on my blog that this message vanished after they start using a SSDT that was generated by ssdtPRGen.sh?

Also. At least two people had P-States without the patch so I don't know what is going on.

 

@frankiee,

 

First of all. His SSDT isn't that different at all, but what stands out is that he removed the extra P-State that was required for other Ivy Bridge processors. Not to mention that the values he is using for APLF and APSN make no sense whatsoever. Not if you check the disassembled code.

 

Also. To put this into perspective: People like you should keep in mind that we all try to improve stuff, as a hobby in our free time, and that I have put a tremendous amount of time into ssdtPRGen.sh so posting something like what you did here is not done.

 

p.s. And when Balamut did compile a working kext for you, after he changed something in my kext, then he should at least report the problem!

[frankiee]

@frankiee,

 

First of all. His SSDT isn't that different at all, but what stands out is that he removed the extra P-State that was required for other Ivy Bridge processors.

 

Yeah, but that change makes it actually work! Just look at my screenshots.

 

 

Not to mention that the values he is using for APLF and APSN make no sense whatsoever. Not if you check the disassembled code.

 

Again, at least it works! And your proposal for improving this would be exactly what? I think we are all interested in improving things, so if you have a better idea, please let us know!

 

 

Also. To put this into perspective: People like you should keep in mind that we all try to improve stuff, as a hobby in our free time, and that I have put a tremendous amount of time into ssdtPRGen.sh so posting something like what you did here is not done.

 

Ah I know that! But what I do not understand is why you insist that your code is OK, when you apparently never tested this configuration? Since I develop software myself (albeit quite different stuff ...) I know that bugs just happen. But what can be a bit annoying is just blaming everything on the user, instead of double checking first.

 

 

p.s. And when Balamut did compile a working kext for you, after he changed something in my kext, then he should at least report the problem!

 

Yeah, I do not know what he did, all I can say that it works now. Maybe you just ask him?

[Pike R. Alpha]

Yeah, but that change makes it actually work! Just look at my screenshots.

 

Again, at least it works! And your proposal for improving this would be exactly what? I think we are all interested in improving things, so if you have a better idea, please let us know!

 

Ah I know that! But what I do not understand is why you insist that your code is OK, when you apparently never tested this configuration? Since I develop software myself (albeit quite different stuff ...) I know that bugs just happen. But what can be a bit annoying is just blaming everything on the user, instead of double checking first.

 

Yeah, I do not know what he did, all I can say that it works now. Maybe you just ask him?

If removing the extra P-State makes it work, now, well that is great. But that actually didn't work before. You can read that in a certain other forum where people tried everything... with the exact same processor. Also. Don't expect someone to own every single Intel processor. just to help other people for free. That is ridiculous.

 

I helped people with this problem and I am actually still trying to help, but what exactly was your contribution other than testing stuff from other people?

 

I never "insisted" (anywhere) that my code is right. In fact. One of the reasons I developed AICPUPMI was to get the lowest possible frequency from people who installed the kext, since that info is missing from the Intel data sheets. And yeah. It crashes. So be it. You wrote software yourself so... bad {censored} happens. Luckily for you I do things a lot better over at Google Inc. so that you and everyone else on this planet can use our search engines... like we want you to use it :-)

 

When someone takes work from someone else, then it is normal to give back. That's how open source works.

[frankiee]

If removing the extra P-State makes it work, now, well that is great. But that actually didn't work before. You can read that in a certain other forum where people tried everything... with the exact same processor.

 

Well, but why do you say then that your script provides the correct values when really nobody got it to work? I still do not get it. And at least for LGA2011 it is no wonder, bc this is why omni patched the kext! The values were all there, but CPU simply not detected. (No wonder ...) This seems to be the missing link to make it actually work. And I think now it does. All we have to do now is to recheck the APSS values for each LGA2011 CPU, maybe same prob with 3930K users. Seems like if you have the wrong configuration here, you are stuck at one or two P-States. Heck even _deleting_ the APSS values completely gives better results than having the wrong ones it seems. Just look at my findings above.

 

 

Also. Don't expect someone to own every single Intel processor. just to help other people for free. That is ridiculous.

 

Did I ever say that I expect this? That was not the point.

 

 

I never "insisted" (anywhere) that my code is right. In fact.

 

In fact, to quote from your blog:

 

 

Sure. The 4930K is supported.

 

 

May I ask what script that it is that you are referring to?

In case you are talking about ssdtPRGen.sh then have a look for yourself:

http://ark.intel.com/nl/products/77780/Intel-Core-i7-4930K-Processor-12M-Cache-up-to-3_90-GHz

In short. All values are fine.

 

Yes, I am talking about ssdtPRGen.sh. (Emphasis mine)

 

Luckily for you I do things a lot better over at Google Inc. so that you and everyone else on this planet can use our search engines... like we want you to use it :-)

 

When someone takes work from someone else, then it is normal to give back. That's how open source works.

 

Google search is open source?

 

And what do you expect in terms of "giving back"? Since I am a relative noob in terms of hackintosh, and do quite different stuff than dealing with ACPI and kext patching - what shall I do?

 

So I try my best what I can - and if only participating in testing and giving feedback, like in this thread. Also I wrote a little guide here in this forum. Better than nothing? And if I wouldn't use about 100% of my spare time to make my machine just work correctly, I would gladly prefer contributing with stuff I know better, like designing a nice theme for clover. Also if you ever should have a question regarding Javascript, CSS or HTML (which I assume you never will, since you are at Google but anyway) feel free to ask me, I will gladly try to help. Deal?

[omni]

Pike,

 

So you are the one responsible for search filtering then and why I don't get full results when I search for things? Instead they are tailored and sanitized to my associations and personal preferences...

 

http://www.ted.com/talks/eli_pariser_beware_online_filter_bubbles.html

 

By the way, there's no reason to toss around names like Google, etc, as that is not going to put more credibility into anything. Many of us here have quite an extensive background in the hackint0sh community, going all the way to the very beginnings.

 

Anyway, perhaps we can focus on topic at hand please. No one is belittling your contributions and we all appreciate what you've done so far. You just need to consider that there could be errors or omissions - as you said someone can't own every single Intel CPU.

 

What can be done to get Cx_IRT MSRs initialized and where/how do the values get compiled for them? Running RevoBoot is not an option, sorry, as that's not a main-stream boot loader - Chameleon or Clover only.

 

You've obviously spent some time looking at the disassembly of AICPM, so sharing some of the insights there would help, too.

 

 

[Pike R. Alpha]

The reference to Google Inc. is one to let people know that this is just another hobby project. That this is not part of my daily tasks. Not to mention that I don't get paid for it. That there is no rush, but there are rules and exceptions when it comes to error reporting. But in the end it was me who, thanks to Google Inc, got the first set of Haswell processors on his desk. I bet that I will also be one of the first folks to get a new set of processors on my desk, in a couple of months from now, so it certainly helps to be part of the Google clan. In short. It has nothing to do with credibility. I don't need that. I already know who I am and what I (can) do.

 

Great to see people from back in the day. I mean. Not too many people know that I introduced my father to the scene. I'm part of it since late 2007 already.

 

I also understand that RevoBoot isn't an option, but I couldn't care less about anything else. Nope. I don't care about what people use, but like I said in one of my blog comments... it certainly helps me to fix things more easily. About the spot where to add them... that's up to the Clover devs. Not me. And I did point you to BITS already so getting the values should be easy.

 

About the errors and omissions. Sure. Apple keeps changing stuff so I am the last person to state otherwise or ignore errors caused by these changes. Which is why I keep asking other people for help. To improve ssdtPRGen.sh But to blame me for it is unfair. Certainly when I get no help from these people.

 

Also. You'll be one of the first people to know when I am ready to share my findings... when it fits my time schedule.

[Balamut]

Jeez Loise, things I've missed ....

 

@omni:

Maybe, but when APSN value is set to the max OSX with push the CPU to the max freq. even on the mundane tasks.

I'll thinker more with it.

 

 

@Pike R. Alpha: I didn't modify anything on AICPUMI, it's yours from tony's place (Even though I don't like that place). Trust me if I make changes or find something I will share it with the community as I did with ApleRTC and cmos reset

 

In regards of ssdtGen, I wasn't about to say or report anything until I was 100% sure that the issue was/is in the script and not in something I did or missed, and thank you I've learned a lot from it.

 

With the reporting: I think both of you are right, look at the HWmonitor, AICPUPMI and IPG logs (not the graphs), the the wattage jumps which shows movement, but the multipliers and freq. have only 3 states, low, maxnoneturbo and max.

 

Now for some odd reason I can't get osx to accept PluginType =1 from clover itself to test slices States generation, but from what I can see and deduct, the original AICPU will not get states from neither SSDT nor clover, but the patched version does the job.

 

Thank you to all of you for amazing work you boys and gals do, now let's play nice

 

On the side note: I think I actually have to get up my lazy ass and finally manually patch the bios for P9X79-E WS.

[omni]

The reference to Google Inc. is one to let people know that this is just another hobby project. That this is not part of my daily tasks. Not to mention that I don't get paid for it. That there is no rush, but there are rules and exceptions when it comes to error reporting. But in the end it was me who, thanks to Google Inc, got the first set of Haswell processors on his desk. I bet that I will also be one of the first folks to get a new set of processors on my desk, in a couple of months from now, so it certainly helps to be part of the Google clan. In short. It has nothing to do with credibility. I don't need that. I already know who I am and what I (can) do.

 

Great to see people from back in the day. I mean. Not too many people know that I introduced my father to the scene. I'm part of it since late 2007 already.

 

I also understand that RevoBoot isn't an option, but I couldn't care less about anything else. Nope. I don't care about what people use, but like I said in one of my blog comments... it certainly helps me to fix things more easily. About the spot where to add them... that's up to the Clover devs. Not me. And I did point you to BITS already so getting the values should be easy.

 

About the errors and omissions. Sure. Apple keeps changing stuff so I am the last person to state otherwise or ignore errors caused by these changes. Which is why I keep asking other people for help. To improve ssdtPRGen.sh But to blame me for it is unfair. Certainly when I get no help from these people.

 

Also. You'll be one of the first people to know when I am ready to share my findings... when it fits my time schedule.

 

 

Thank you Pike, we'll anxiously await your findings.

 

[Balamut]

@Pike R. Alpha off topic: Dude I didn't know about your sister, my condolences

[shilohhh]

Version 3 with or without suggested mods to SSDT KPs my system after about 3-5 seconds (3930K)

 

Mods to SSDT in version 2 cause no change. Still locked at 1200. CStates and PStates show loaded in IOReg.

[Klonkrieger2]

HI  Klonkrieger2, I have same CPU of you. But 3600 is max turbo state for one cpu. For all ten you have 3300 max turbo 

If possible , Could you share unpatched and patched firmware version  of your motherboard?

Thank you

 

Hi fabsiosun. Due to the origin of my system it's not possible to share the bios/firmware of my motherboard. (I'm sorry!)

With the Turboboost you are probably right. I just compared my system with other cpus and i then thought it must be 3600 for my CPU.

 

Do you have working power management?

[yangshun1029]

I have a 4 core CPU - I7 3820，if i just use patched kext and don't use ssdt,the cpu will stuck at 12x.

 

Here is the screen with the patched kext and a custom SSDT, generated by Pikes script

 

 

Frequency is actually changing, Not much, but I got frequencies from  3.6 to 3.7 GhZ while testing.

 

Ues MSRDumper.kext i can see 12 36 37, 3 Pstate,but most of time frequencies is just from  3.6 to 3.7 GhZ

 

I really dont know why i still got wrong iInformation like this: 

14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::getCPUCStates - C000 ACST and _CST evaluations failed!
14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::getCPUCStates - _CST did not return a package
14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::getCPUPStates - C000 APSS and _PSS evaluations failed!
14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
14-1-20 19:33:42.000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1

Here is my ssdt,help me!

ssdt.aml.zip

[frankiee]

your SSDT seems to be missing most ACST method definitions. You have them defined for a singel core (/SB.C000) but not the rest.

 

To solve, just include a reference to the ACST method in _each_ core, like you did with APSS.

 

So it should look like this:

Scope (\_SB.C001)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

Do this for the rest of your cores and it should work.

Version 3 with or without suggested mods to SSDT KPs my system after about 3-5 seconds (3930K)

 

Mods to SSDT in version 2 cause no change. Still locked at 1200. CStates and PStates show loaded in IOReg.

 

 

Are you sure you have the correct SSDT? Maybe wrong frequency values, like it was with my case.

Edited January 20, 2014 by frankiee

[yangshun1029]

your SSDT seems to be missing most ACST method definitions. You have them defined for a singel core (/SB.C001) but not the rest.

 

To solve, just include a reference to the ACST method in _each_ core, like you did with APSS.

 

So it should look like this:

Scope (\_SB.C001)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

Do this for the rest of your cores and it should work.

 

 

Are you sure you have the correct SSDT? Maybe wrong frequency values, like it was with my case.

 

I ues a custom SSDT, frequency values generated by Pikes script

[frankiee]

Yangshun I meant shilohhh with the last sentence. You have to edit your SSDT like I showed, that should do it. But I wonder about your SSDT a bit since Pike's script should insert this methods anyway. Maybe you try to generate that again first, with the latest version?

[yangshun1029]

Yangshun I meant shilohhh with the last sentence. You have to edit your SSDT like I showed, that should do it. But I wonder about your SSDT a bit since Pike's script should insert this methods anyway. Maybe you try to generate that again first, with the latest version?

curl -o ssdtPRGen.sh https://raw.github.com/Piker-Alpha/RevoBoot/clang/i386/libsaio/acpi/Tools/ssdtPRGen.sh
chmod +x ssdtPRGen.sh
./ssdtPRGen.sh

I use this to  generate my ssdt,i think that will generate the latest version,but there is no methods ACST in (\_SB.C001) just APSS.

 

I will add method and try again

[kundica]

Version 3 with or without suggested mods to SSDT KPs my system after about 3-5 seconds (3930K)

 

Mods to SSDT in version 2 cause no change. Still locked at 1200. CStates and PStates show loaded in IOReg.

 

Hey Shilohhh, I think it's a bios conflict.  Version 3 caused KP for me with 4206, but boots fine with 4702 and 4802.  I'm currently getting 3 states with 4802... 12, 32, and 38.  HWSensors and IPG give me strange readings though.  My processor appears to use the amount of power it would at 12x, but always seems to idle at 32x according to both apps.  I plan to run some more extensive tests today and report my findings.

 

For those of you who keep getting panics with AICPUMI, trying compiling it from Pike's source.  I no longer get panics or freezes after doing that.

[yangshun1029]

thanks all the guys,i seems right,no fail again!

14-1-20 23:10:54.000 kernel[0]: MSRDumper PStatesReached: 12 36 37 38 

Have 4 Pstate now

ssdt.aml.zip

[oswaldini]

yangshun1029, can you post your SSDT. I can't get PM on 4930K. I'm stuck at 12 or 32. With Null... I get 12 and 32.

[frankiee]

Oswaldini: use the SSDT posted by Balamut. This works at least for me (also on 4930K)

Yangshun: Test by running Intel Power Gadget. This gives a better impression imho. AICPUPMI also did not show as many P-States as were apparently reached (of course, _if_ the output of IPG is correct)

[yangshun1029]

00:42:30:311,3836265300564,0.259302, 1200,  23.663,   4.730,   1.314,   7.460,   1.491,   
0.414, 29,0,130
00:42:30:512,3836988776772,0.460285, 3600,  23.055,   9.363,   2.601,   6.822,   2.862,   0.795, 29,0,130
00:42:30:711,3837705227358,0.659298, 3800,  22.748,  13.890,   3.858,   6.564,   4.169,   1.158, 28,0,130
00:42:30:912,3838428729004,0.860270, 3600,  21.710,  18.254,   5.070,   5.504,   5.275,   1.465, 28,0,130
00:42:31:111,3839145659016,1.059416, 3600,  19.662,  22.169,   6.158,   3.427,   5.957,   1.655, 29,0,130
00:42:31:312,3839868782248,1.260282, 3600,  19.630,  26.112,   7.253,   3.413,   6.643,   1.845, 29,0,130
00:42:31:512,3840588863404,1.460322, 3600,  19.630,  30.039,   8.344,   3.429,   7.329,   2.036, 29,0,130
00:42:31:712,3841308792828,1.660301, 3600,  20.485,  34.136,   9.482,   4.250,   8.179,   2.272, 28,0,130
00:42:31:911,3842027596968,1.859968, 3600,  19.372,  38.004,  10.557,   3.228,   8.823,   2.451, 28,0,130
00:42:32:112,3842748751576,2.060287, 3600,  19.658,  41.941,  11.650,   3.389,   9.502,   2.639, 28,0,130
00:42:32:311,3843465929808,2.259502, 1200,  19.460,  45.818,  12.727,   3.294,  10.158,   2.822, 29,0,130
00:42:32:512,3844188742092,2.460302, 3600,  19.818,  49.798,  13.833,   3.584,  10.878,   3.022, 29,0,130
00:42:32:712,3844908834388,2.660326, 3600,  20.097,  53.818,  14.949,   3.876,  11.653,   3.237, 28,0,130
00:42:32:911,3845627096656,2.859842, 3600,  19.414,  57.691,  16.025,   3.251,  12.302,   3.417, 28,0,130
00:42:33:111,3846345318880,3.059347, 3600,  23.927,  62.465,  17.351,   7.729,  13.844,   3.846, 29,0,130
00:42:33:312,3847068818560,3.260319, 3600,  22.734,  67.033,  18.620,   6.483,  15.147,   4.207, 28,0,130
00:42:33:511,3847787846718,3.460065, 3700,  23.096,  71.647,  19.902,   6.898,  16.525,   4.590, 32,0,130

If i use IPG 3.0.1,the frequency actually change but the IPG did not show it

 

If i use IPG 2.5.2,the frequency show it like this:

 

[frankiee]

You also should check if your "Name (APSN, 0x02)" SSDT value is correct. Must match the number of Turbo states that your CPU model can reach. "0x02" would mean that your CPU only has 2 Turbo states. Ist that correct? Otherwise your numbers look a bit like mine before it was fully working. So I think you're almost there.

[Klonkrieger2]

Well this is odd...

 

When changing in the SSDT the APSN pointer? to the 1200 MHz entry, IPG shows me all frequency values between 1200MHz and 3600MHz. However HWMon tells me that i only reach all turbo 30 to 36. AICPUPMI the same... Even the state residency is always at 0x0, so things are still not quite right. but i my opinion this is interesting...

        Name (APLF, 0x04)
        Name (APSN, 0x25)
        Name (APSS, Package (0x1E)
        {
            /* Workaround for the Ivy Bridge PM 'bug' */
            Package (0x06) { 0x0E11, 0x01FBD0, 0x0A, 0x0A, 0x2500, 0x2500 },
            /* High Frequency Modes (turbo) */
            Package (0x06) { 0x0E10, 0x01FBD0, 0x0A, 0x0A, 0x2400, 0x2400 },
            Package (0x06) { 0x0DAC, 0x01FBD0, 0x0A, 0x0A, 0x2300, 0x2300 },
            Package (0x06) { 0x0D48, 0x01FBD0, 0x0A, 0x0A, 0x2200, 0x2200 },
            Package (0x06) { 0x0CE4, 0x01FBD0, 0x0A, 0x0A, 0x2100, 0x2100 },
            Package (0x06) { 0x0C80, 0x01FBD0, 0x0A, 0x0A, 0x2000, 0x2000 },
            Package (0x06) { 0x0C1C, 0x01FBD0, 0x0A, 0x0A, 0x1F00, 0x1F00 },
            /* High Frequency Modes (non-turbo) */
            Package (0x06) { 0x0BB8, 0x01FBD0, 0x0A, 0x0A, 0x1E00, 0x1E00 },
            Package (0x06) { 0x0B54, 0x01E552, 0x0A, 0x0A, 0x1D00, 0x1D00 },
            Package (0x06) { 0x0AF0, 0x01CF3F, 0x0A, 0x0A, 0x1C00, 0x1C00 },
            Package (0x06) { 0x0A8C, 0x01B995, 0x0A, 0x0A, 0x1B00, 0x1B00 },
            Package (0x06) { 0x0A28, 0x01A453, 0x0A, 0x0A, 0x1A00, 0x1A00 },
            Package (0x06) { 0x09C4, 0x018F79, 0x0A, 0x0A, 0x1900, 0x1900 },
            Package (0x06) { 0x0960, 0x017B05, 0x0A, 0x0A, 0x1800, 0x1800 },
            Package (0x06) { 0x08FC, 0x0166F7, 0x0A, 0x0A, 0x1700, 0x1700 },
            Package (0x06) { 0x0898, 0x01534F, 0x0A, 0x0A, 0x1600, 0x1600 },
            Package (0x06) { 0x0834, 0x01400A, 0x0A, 0x0A, 0x1500, 0x1500 },
            Package (0x06) { 0x07D0, 0x012D29, 0x0A, 0x0A, 0x1400, 0x1400 },
            Package (0x06) { 0x076C, 0x011AAB, 0x0A, 0x0A, 0x1300, 0x1300 },
            Package (0x06) { 0x0708, 0x01088E, 0x0A, 0x0A, 0x1200, 0x1200 },
            Package (0x06) { 0x06A4, 0x00F6D1, 0x0A, 0x0A, 0x1100, 0x1100 },
            Package (0x06) { 0x0640, 0x00E575, 0x0A, 0x0A, 0x1000, 0x1000 },
            Package (0x06) { 0x05DC, 0x00D478, 0x0A, 0x0A, 0x0F00, 0x0F00 },
            Package (0x06) { 0x0578, 0x00C3D9, 0x0A, 0x0A, 0x0E00, 0x0E00 },
            Package (0x06) { 0x0514, 0x00B398, 0x0A, 0x0A, 0x0D00, 0x0D00 },
            /* Low Frequency Mode */
            Package (0x06) { 0x04B0, 0x00A3B3, 0x0A, 0x0A, 0x0C00, 0x0C00 },
            Package (0x06) { 0x044C,     Zero, 0x0A, 0x0A, 0x0B00, 0x0B00 },
            Package (0x06) { 0x03E8,     Zero, 0x0A, 0x0A, 0x0A00, 0x0A00 },
            Package (0x06) { 0x0384,     Zero, 0x0A, 0x0A, 0x0900, 0x0900 },
            Package (0x06) { 0x0320,     Zero, 0x0A, 0x0A, 0x0800, 0x0800 }
        })