Jump to content

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


  • Please log in to reply
553 replies to this topic

#41
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything

Still stuck at 12x ....



#42
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

Still stuck at 12x ....

 

Do you really have an 8-core CPU, because your turbo states show as that?

 

Let's see your SSDT and your dmesg boot log with my debug flags, as per OP. Please put them up on pastebin?



#43
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything

Do you really have an 8-core CPU, because your turbo states show as that?

 

Let's see your SSDT and your dmesg boot log with my debug flags, as per OP. Please put them up on pastebin?

 

No I have a 6 core CPU - 4930K to be precise. My System SSDT contains in fact only the "CpuPm" table, but this is a real monster, with a whopping 378144 lines of code!!! OMG, that's the only thing I can say .... I have no clue what is happening there. Of course I can upload this beast, but first of all, I will share my latest findings:

 

So I played a bit with some settings and the Intel Power Gadget. Here is the original state, stuck at 34x and no PM. Note that in all of these screens I show a geekbench run, and the idle phase thereafter.

 

Spoiler

So lots of heat and power wasted, running Geekbench does not add much further then - not good!

 

next, here is the screen with the patched kext and a custom SSDT, generated by Pikes script:

 

Spoiler

So much less energy and heat emitted, but unfortunately stuck at that at the same time. (12x Multiplier). Actually Geekbench was also 3x slower.

 

Now, things get interesting. I thought that there might be something wrong with Pikes script. I deleted everything except the ACST method, since without that you get the _ACST error messages. I also had to leave Name (APSN, 0x05) or else I would get a message that max Turbo state could not be detected. I did NOT drop the original SSDT and merely added this one. But still I am stuck at x12!

 

Now, things get even more interesting! Next step was to DROP the system SSDT table.

 

Then I get these error messages:

18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C000 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C001 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C002 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C003 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C004 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C005 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C006 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C007 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C008 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C009 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C00A APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C00B APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!

Yeah, so the tables are missing completely! But look at the result:

 

Spoiler

 

So you see that the frequency is actually changing now! Not much, but I got frequencies from around 2.7 to 3.7 GhZ while testing. And also Power consumption now actually fluctuates MUCH more - depending what I am doing - ranging from 9W to 80W. But I still do not get it ... Surely this may be not the final solution but looks way better to me. But why? Would never have expected it this way.



#44
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

Now, things get even more interesting! Next step was to DROP the system SSDT table.

 

Then I get these error messages:

18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C000 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C001 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - C002 APSS and _PSS evaluations failed!
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
18/01/14 22:09:55,000 kernel[0]: X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!

 

 

Ok, so use Pike's script to generate your P-States but replace his ACST method with the one I provided in the OP.

 

Make sure to Drop your system SSDT, include APSN (0x05) and APLF (0x00) in C000 scope, and see what happens, I think you are getting pretty close.



#45
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything

Ok, so use Pike's script to generate your P-States but replace his ACST method with the one I provided in the OP.

 

Make sure to Drop your system SSDT, include APSN (0x05) and APLF (0x00) in C000 scope, and see what happens, I think you are getting pretty close.

 

When I do exactly that, I am at x12 again. When I delete his APSS entries and all references, PM is back (albeit with all these errors shown above). And in fact when I look at my output, it seems that this is actually working, including Turbo. I mean 10W idle consumption, is that supposed to go even lower? Still wondering why it is still showing me around x34 most of the time then, with only occasional downward spikes.

 

So it does not seem to matter which ACST method I use. FWIW I also looked at my System SSDT and there I found a NPSS entry, linked from _PSS - which looked a bit different, conatining less states. But when using that (by copying to my SSDT and renaming to APSS) - I am at x12 again.

 

So I seem to miss the correct entries for APSS?



#46
Balamut

Balamut

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts

For i7-4930k put

Use this for SSDT, make sure to drop CpuPm tables, P,C states off in Clover.
 
http://pastebin.com/cwtfAN47

Also pikes script is wrong on the P-states for the IvyBridge-E cpu (for one It's IvyBridge not Haswell and, I think - i7-4930k's lowest state is 1200 not 800).
 
Omni: I will give you full report with debug logs later on today.
 
For people with bios lock and kernel panics use AppleIntelCPUPowerManagementInfo.kext I've attached.
 

Look at the Power Gadget Graphs

Spoiler

 

Edit: APSN is MaxNoneTurbo State in Hex

Attached Files



#47
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

Yeah, 800 is only achievable on the mobile CPUs, afaik.

 

I also suggest to try my ACST instead of Pike's, as mine came from nMP.



#48
Balamut

Balamut

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts

As promised x86Platform Logs

http://pastebin.com/raw.php?i=8QnCHHep

 

AICPUPMI

http://pastebin.com/raw.php?i=mFTyPT07

 

On the side note, the lowest package on the IvyBridge-E need to be 1100mhz or else the lowest P State will be 13 (1300mhz).

 

Spoiler

 

 

 



#49
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

That looks fine, I just don't understand why you have C3 Residency at 0x0.

 

Have you tried using my ACST method I posted in the first post instead of Pike's generated/original SSDT one you have?

 

Also, it seems AICPMI is just not accurate at reporting P-states, at least not for the IB/SB Xeon core CPUs. You have to leave it running for a while and even then you will not see them all. Either that, or Mavericks is way too busy to relax and run at a lowest states.

 

But that can't be it, because when running HWMonitor I see my CPU Package Cores drop to below 2W and CPU Package Total below 11W usage, and I have a dual 2.6GHz setup so they could not possibly be running at 26x and consume only 11W.

 

Something is not reporting properly, either AICPMI or HWMonitor.



#50
Balamut

Balamut

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts

That looks fine, I just don't understand why you have C3 Residency at 0x0.

Maybe clover have something to do with it.
 

Have you tried using my ACST method I posted in the first post instead of Pike's generated/original SSDT one you have?

Also, it seems AICPMI is just not accurate at reporting P-states, at least not for the IB/SB Xeon core CPUs. You have to leave it running for a while and even then you will not see them all. Either that, or Mavericks is way too busy to relax and run at a lowest states.

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

 

But that can't be it, because when running HWMonitor I see my CPU Package Cores drop to below 2W and CPU Package Total below 11W usage, and I have a dual 2.6GHz setup so they could not possibly be running at 26x and consume only 11W.
 
Something is not reporting properly, either AICPMI or HWMonitor.

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

Attached Files



#51
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

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. :)

 



#52
Pike R. Alpha

Pike R. Alpha

    InsanelyMac Geek

  • Developers
  • 215 posts
  • Gender:Male

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/P...evoBoot/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.



#53
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

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?

 



#54
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything

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:

 

Spoiler

 

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?



#55
Pike R. Alpha

Pike R. Alpha

    InsanelyMac Geek

  • Developers
  • 215 posts
  • Gender:Male

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!



#56
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything
@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?



#57
Pike R. Alpha

Pike R. Alpha

    InsanelyMac Geek

  • Developers
  • 215 posts
  • Gender:Male

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.



#58
frankiee

frankiee

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 215 posts
  • Gender:Male
  • Location:Earth
  • Interests:Everything

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...-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?



#59
omni

omni

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 286 posts
  • Gender:Male

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/t...er_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.

 



#60
Pike R. Alpha

Pike R. Alpha

    InsanelyMac Geek

  • Developers
  • 215 posts
  • Gender:Male

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.







0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy