Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
omni

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

566 posts in this topic

Recommended Posts

Maybe clover have something to do with it.

 

I didn't use his, attaching ssdt, take a look if you can, maybe I screwed up somewhere

 

 

Could be, but coming from intels power gadget you can see cpu idling at 1200mhz ~6W.

 

Your SSDT ACST method appears exactly the same as mine, but are you dropping your system SSDT, because you really should?

 

What I believe to be incorrect is your APSN entry - it should be 0x05 (value should be an index not a multiplier). Thats your 22x multiplier which is your max-non turbo state (normal operating CPU clock).

 

As for APLF, I though that value stores the max efficient power state, which in your case should be 0x1C.

 

Oh, and add both APSN and APLF to all CPU scopes as that's what the original Apple SSDT does.

 

Intel Power Gadget is probably correct in those readings, which means that AICMPI is probably not entirely accurate and should be used in combination with other readings only.

 

Bottom line is that your SpeedStep appears to be working, according to IPG readings. :)

 

 

Share this post


Link to post
Share on other sites

Intel Power Gadget is probably correct in those readings, which means that AICMPI is probably not entirely accurate and should be used in combination with other readings only.

No. Your assumption is not correct. AppleIntelCPUPowerManagementInfo.kext is correctly reading all reached package P-States stored by calls to wrmsr 0x199 in XCPM and AppleIntelCPUPowerManagement – see the disassembled code, but Apple is using limiters when it comes to writing the MSR we read. Hence the limited number of P-States people see with certain model identifiers. One example is the iMac. Remember?

 

The difference is that the Intel Power Gadget does it differently. It shows you the actual wattage, and uses that to calculate other stuff. The question now is what do people want to see? The data stored by Apple or what the Intel Power Gadget shows you.

 

I like to add that when I made a test version available on my blog. One that does it the Intel Gadget way, that people immediately started to say that it shows the wrong P-States. In short. Make up your mind folks ;)

 

@Balamut,

 

When something isn't right, then please contact the developer (me) over at https://github.com/Piker-Alpha/RevoBoot/issues 

so that things can be fixed. Oh wait. I already did that...

 

@omni,

 

I see you added debug storage to see if the _CST method is being called, so is it? Please note that this wasn't the case!

 

Also. I had two reports in my blog from people with working Turbo P-States without a bin-patch, be it limited, so I still don't understand why you need to bin-patch stuff.

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
Share on other sites

Seems like I have now finally success on my side! :thumbsup_anim:

 

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:

 

 

5SDZEFT.png

 

 

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?

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
@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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

The X86Platform debug log, looks really fine, except one thing: maxGuaranteedTurboPState 4, freq 3300 & using maxFreq 3300

 

This should be 3600MHz. But anyway I reach 3600Mhz....

Also the max efficient p-state is correct. (1200MHz)

 

@omni: any progress on a new version? I would like to test something knew, if you have anything 

 

EDIT: after a while 0xE2 gets changed to 0x401 which means lowest C-State is C2

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

 

At this moment no. and without patching I can use only previous AICPUPMI version without kpiing.

 

I f I set from Bios max cpu ratio at 36 (that is the max value that our CPU allows, I have 12,33,36

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MWAIT C-States.....................: 4384

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_CORE_THREAD_COUNT......(0x35)  : 0xA0014

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PLATFORM_INFO..........(0xCE)  : 0xC10E4811E00

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PMG_CST_CONFIG_CONTROL.(0xE2)  : 0x8400

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PMG_IO_CAPTURE_BASE....(0xE4)  : 0x10414

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_MPERF.................(0xE7)  : 0x1B29EEF533

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_APERF.................(0xE8)  : 0x145B67EB35

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_FLEX_RATIO.............(0x194) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_IA32_PERF_STATUS.......(0x198) : 0x25A100002400

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_IA32_PERF_CONTROL......(0x199) : 0x2400

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_CLOCK_MODULATION......(0x19A) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_THERM_STATUS..........(0x19C) : 0x88400000

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_MISC_ENABLES..........(0x1A0) : 0x850089

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_MISC_PWR_MGMT..........(0x1AA) : 0x400001

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_TURBO_RATIO_LIMIT......(0x1AD) : 0x2424242424242424

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: IA32_ENERGY_PERF_BIAS......(0x1B0) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_POWER_CTL..............(0x1FC) : 0x2104005B

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_RAPL_POWER_UNIT........(0x606) : 0xA1003

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKG_POWER_LIMIT........(0x610) : 0x68960005AFFFF

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKG_ENERGY_STATUS......(0x611) : 0x69BF0EE

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKGC3_IRTL.............(0x60a) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKGC6_IRTL.............(0x60b) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PP0_CURRENT_CONFIG.....(0x601) : 0x14149480000640

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PP0_POWER_LIMIT........(0x638) : 0x80000000

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PP0_ENERGY_STATUS......(0x639) : 0x5BA391E

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PP0_POLICY.............(0x63a) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKG_C2_RESIDENCY.......(0x60d) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x0

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: Low Frequency Mode.................: 1200 MHz

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: Clock Speed (Max. Non-Turbo Freq.).: 3000 MHz

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: Maximum Turbo Frequency............: 3600 MHz

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: CPU P-States [ (33) 36 ]

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: CPU C6-Cores [ 2 3 4 6 7 8 9 12 13 14 15 16 ]

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: CPU P-States [ (12) 33 36 ]

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: CPU C6-Cores [ 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ]

Jan 20 11:28:12 localhost kernel[0]: AICPUPMI: CPU C6-Cores [ 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ]

 

I can see MSR data only if I patch AICPUPM other ways I see only this

 

Jan 20 11:41:20 localhost kernel[0]: AICPUPMI: CPU P-States [ 33 36 ]

Jan 20 11:41:20 localhost kernel[0]: AICPUPMI: CPU P-States [ 12 33 36 ]

 

If I disable from bios all speedstep and C support I have always first situation but I am stuck at 15 (1.5 Ghz)

 

IPG sees correct temperatures and CPU power Watt, graphical processor frequency is variable from 1.20 Ghz to 3.3 GHz

HW Monitor has a correct W but Cpu frequency pass from 30,31,32,33 and never reach values <30

If Apply NULLCPUPM also HW monitor has frequency from 12 to 33

 

If I disable from bios all CPU I have a max frequency of 3.6 GHz and a cpu package multiplier from 12,30,31,33,34,35 no values from 12 to 30 but for IPG they are there.

 

Could you say which motherboard and firmware are you using?

Thank

Share this post


Link to post
Share on other sites

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

 

7i8y0zn.png

 

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

Share this post


Link to post
Share on other sites

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 by frankiee

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Posts

    • Hello MaLd0n,   Could you please make DSDT edits for my new Skylake desktop Lenovo M910t    RunMe files: https://www96.zippyshare.com/v/5bgqAiga/file.html
        Thank you very much in advance!
    • Have you tried adjusting the Khz in midi pref pane or editing the info plist to suit your needs. that sometimes corrects weird noise behavior.
    • Hello Mald0n:

      Nice to meet you, I have created a post about my problem on High Sierra before and I was redirected to this guide by Allan.

      As mentioned in the post, I was not able to get pass the login screen at initial boot and the system could not shutdown occasionally.

      However I solve the high temperature problem when I replace the clover folder you provide on first post, currently the cpu temperature is around 5x-6x'c after 10 mins up time.

      Attached is the clover folder, ioreg as well as the send me app, thanks for your help!

      p.s. I notice that your clover boot efi is a old traditional grey apple boot logo, Is there a version of modern dark and white logo one that I could replace with? Thank you!

      https://www.insanelymac.com/forum/topic/333867-cant-get-pass-2nd-stage-boot-logo-on-initial-boot-and-high-temperature/   My system:
      Gigabyte GA-X48-DQ6
      Core 2 Extreme QX9650 C0
      4 x Kingston DDR2 800ghz Ram
      Galaxy GTX460 1GB
      120GB SSD Leven JS500120C, high Sierra installed
      250GB seagate ST3250310AS
      250GB WDC WD2500JS-08NCB1
      File: https://drive.google.com/file/d/1_k3_jxvzGaLfDzin0zSAUT5ml16Hq15c/view?usp=sharing      
    •   Still garbled sound in earphone. The speaker is loud as previous. louder than 2.9.1   
    • Up for https://sourceforge.net/p/cloverefiboot/wiki,


×