Jump to content
469 posts in this topic

Recommended Posts

About AppleLPC. I have 8b49 in Toshiba P50-A and it's not present in AppleLPC, because of that i must inject it.

Understood...

I wrote about binpatch in Clover topic on projectosx. I hope you don't mind. It would be great if this can be implemented in Clover kernelpatcher.

Do you have a link to your post there? I looked but didn't find a reference... I see that Clover does not have the generic patching capability for mach_kernel as it does for kext binaries. Just hardcoded options for Kernel CPU (not sure what that one is) and Kernel Lapic (I know what that one is). It would be useful.

Do you have a link to your post there? I looked but didn't find a reference... I see that Clover does not have the generic patching capability for mach_kernel as it does for kext binaries. Just hardcoded options for Kernel CPU (not sure what that one is) and Kernel Lapic (I know what that one is). It would be useful.

 

 

http://www.projectosx.com/forum/index.php?showtopic=2562&st=11620&gopid=37219&&do=findComment&comment=37219

http://www.projectosx.com/forum/index.php?s=&showtopic=2562&view=findpost&p=37211 - english is not my first language, I write poorly but I understand pretty good :)

 

EDIT: Your binpatch is easy to add to Clover, we can do it like KernelLapic: http://www.projectosx.com/forum/index.php?showtopic=2562&st=8020&p=31107&hl=kernellapic&&do=findComment&comment=31107

 

I'm not a programmer but after careful reading I think I can adjust KernelLapic sample for your patch. 

http://www.projectosx.com/forum/index.php?s=&showtopic=2562&view=findpost&p=37211 - english is not my first language, I write poorly but I understand pretty good :)

That is a better description...

 

The discussion seems to focus on injection as if that is somehow easier that simply putting the right mach_kernel at /mach_kernel on the target boot volume?

 

But what you really want is search/replace for mach_kernel, much like Clover has for kexts.

 

Also, I would be surprised if the patch I wrote doesn't break in future versions. It is probably the kind of thing that needs to be looked at carefully with each release. Next step is to see if I can make xcpm work on this computer, then maybe try to cleanup the patch a bit (somehow make it simpler).

  • Like 1

Please note: I have constructed a patch for mach_kernel to avoid the instant reboot. See post #1 and my blog for details.

 

Now running w/ native xcpm and MacBookPro11,2 smbios...

  • Like 1

Please note: I have constructed a patch for mach_kernel to avoid the instant reboot. See post #1 and my blog for details.

 

Now running w/ native xcpm and MacBookPro11,2 smbios...

How many p-states do you have? Still only Turbo?

How many p-states do you have? Still only Turbo?

See post #1. Best pstate distribution is still with MacBookPro8,3.

Hello @RehabMan which SMBios highest suits my i7 3770k.I use Macmini 6,2 and this mach_kernel http://www.insanelymac.com/forum/files/file/173-109-kernel-xcpm-free/

Tell me what to do to me for sure my good speedstep.When to do patch for kernel after and befor instal OS X?

Thank you.

Hello @RehabMan which SMBios highest suits my i7 3770k.I use Macmini 6,2 and this mach_kernel http://www.insanelymac.com/forum/files/file/173-109-kernel-xcpm-free/

Tell me what to do to me for sure my good speedstep.When to do patch for kernel after and befor instal OS X?

Thank you.

That kernel is the same as the one posted here. If you follow my logic in post #1, the best result (widest range of pstates) would be with a Sandy Bridge style SSDT (no plugin-type injection) and MacMini5,x (Sandy Bridge Mac Mini).

 

But since this is a desktop, you could also use iMac14,2 and patched retail kernel (see blog for patch). If your board has locked MSRs, of course, you would need to use the patched kernel whenever booting OS X, during installation or after.

 

If you're using the kernel you mention, there is no need to patch it (unless you also have Local APIC panic).

If you're using the kernel you mention, there is no need to patch it (unless you also have Local APIC panic).

Yes I use this kernel and macmini 6,2. and my pState work this in MSRDumper:

t06p1t.png

I'll try later with the iMac 14,2.

Yes I use this kernel and macmini 6,2. and my pState work this in MSRDumper:

t06p1t.png

I'll try later with the iMac 14,2.

Without seeing your SSDT or ioreg dump, it is not possible to really see what you have going on there.

Look this is my IOReg and SSDT.Please look and tell me what you mean.

Thanks...

You're actually using MacPro5,1, Ivy SSDT, with an invalid board-id ("Mac-F221BEC8"). That is certainly a combination I have not tried.

  • Like 1

You're actually using MacPro5,1, Ivy SSDT, with an invalid board-id ("Mac-F221BEC8"). That is certainly a combination I have not tried.

I use Mac board 5,1 number and copy in Mac board number macmini 6,2 and replace in X86PlatformPlugin.He works as the mac mini 6.2 and 5.1 shows.

Which number is iMac 14,2?

I use Mac board 5,1 number and copy in Mac board number macmini 6,2 and replace in X86PlatformPlugin.He works as the mac mini 6.2 and 5.1 shows.

That doesn't explain why your board-id is not valid.

 

Which number is iMac 14,2?

Mac-27ADBB7B4CEE8E61

Tip:

 

If you see "Stepper CPU" under IOPMrootDomain -> Supported Features then XCPM is not driving power management but AppleIntelCPUPowermanagement.kext

Also:

kextstat|grep -y "appleintelcpupowermanagement "

Look how to work for me:

2nbu9v5.png

Yes... to be expected using non-xcpm kernel and MacPro5,1 smbios. Pike is referring to the case where you're using xcpm-enabled kernel (patched for locked MSRs... see my blog for patch), and Haswell era smbios.

Which SMBios for my IvyBridge and which  patch use:

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x5e\x30\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3\x90{3})\x90{4}|\x74\x70${1}\x74\x58${2}\x75\x48${3}\x85\xc9\x74\x07${4}\x75\x95${5}|g' mach_kernel 

or this:

perl -pi -e 's|\xe2(\x00{3}\x02\x00{12}\x04\x00{6}\x07\x00{2}\x1e\x00{20})\xe2(\x00{3}\x0c\x00{12}\x04\x00{6}\x05\x00{2}\x1e\x00{20})\xe2(\x00{3}\x10\x00{12}\x04\x00{6}\x08\x00{2}\x7e\x00{20})|\x00${1}\x00${2}\x00${3}|g' mach_kernel 

or both?

Thank you people 

 RehabMan and Pike R. Alpha!!!!!

Good work.But I don't have a luck.

Which SMBios for my IvyBridge and which  patch use:

By default, OS X does not use xcpm for Ivy Bridge CPUs, not even on real Macs. You can force it with kernel flag "-xcpm" (or maybe "-xcpm=1").

 

 

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x5e\x30\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3\x90{3})\x90{4}|\x74\x70${1}\x74\x58${2}\x75\x48${3}\x85\xc9\x74\x07${4}\x75\x95${5}|g' mach_kernel 
or this:

perl -pi -e 's|\xe2(\x00{3}\x02\x00{12}\x04\x00{6}\x07\x00{2}\x1e\x00{20})\xe2(\x00{3}\x0c\x00{12}\x04\x00{6}\x05\x00{2}\x1e\x00{20})\xe2(\x00{3}\x10\x00{12}\x04\x00{6}\x08\x00{2}\x7e\x00{20})|\x00${1}\x00${2}\x00${3}|g' mach_kernel 
or both?

 

Those patches are from my blog and they are the first patch set I used prior to "Update #1". To have any effect, they must both be applied. The third patch in the blog article is an alternate that must be used only by itself. So, it is either the "first two patches" or only the "third patch."

 

Just for completeness, this is the third (standalone) patch:

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05\x5e\x30\x5e\x00\x85\x47\xdc)\x74\x54(\x8b\x4f\xd8\x45\x85\xc0\x74\x08\x44\x39\xc1\x44\x89\xc1)\x75\x44(\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x57\xf8\x48\x8b\x47\xe8\x48\x85\xc0\x74\x06\x48\xf7\xd0\x48\x21\xc2\x48\x0b\x57\xf0\x49\x89\xd1\x49\xc1\xe9\x20\x89\xd0\x8b\x4f\xd8\x4c\x89\xca)(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce)\x75\x99(\x5d\xc3)\x90{7}|\x74\x73${1}\x74\x5b${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x92${5}|g' mach_kernel

See post #1. Best pstate distribution is still with MacBookPro8,3.

It appears that having a jump in pstates from idle to nominal (in this case x8 to x24) is by design. It appears to be intentional. I loaded AppleIntelCPUPowerManagementInfo.kext on my MacBookAir6,2 and it too jumps from idle (x8) to nominal (x17) with no states in between.

 

If it is good enough for the MacBookAir6,2, it is probably good enough for our hacks...

Clover 2336 Kernel power management patch for haswell with locked msrs

 

Rev 2337: https://dl.dropboxusercontent.com/u/9641107/Clover/Clover_v2k_r2337.pkg.zip

You might want to post the config.plist setting that enables it...

 

Just checked the source code.

It is "KernelPm" option. Place in same section as for "KernelLapic"

×
×
  • Create New...