Haswell early reboot, Mavericks, locked MSRs, and HP Envy 15-J063CL (i7-4700MQ)

[RehabMan]

I wrote this "somewhere else" as well, but I thought this might be interesting here too...

 

Haswell/Mavericks Troubles

 

Many people with Haswell laptops (and some desktops) have been running into a new problem Apple has thrown at us. The new Mavericks kernel has power management moved down into the kernel. For this reason, my MacBookAir6,2 running Mavericks does not load AppleIntelCPUPowerManagement. In the past, we patched AppleIntelCPUPowerManagement to avoid the kernel writing to locked CPU MSRs (machine specific registers, credit RevoGirl). Some BIOSes lock some of these registers (the common one is 0xE2, I don't know if others can be locked as well). The problem is that touching these registers when they are locked causes an unexpected fault and you get a KP. It seems this KP is so early, that the kernel is unprepared to handle it, and the computer reboots.

 

Some people have found that if they use a kernel modified for AMD systems, they are able to boot. I tried this and it indeed works. But other things break... I was able to install (using that kernel), but I couldn't boot with caches (always had to use "-f"). Booting with caches caused a KP. In addition, there was no power management. CPU was running at x24 always.

 

But...

 

I decided to see what I could do by building my own kernel. My main thought was to make some changes, see if I could avoid touching locked MSRs with modifications to the source code with the idea to fold the changes into a patch. So, I downloaded the kernel source from opensource.apple.com, found out how to build it (thanks google!), and tried to use it. On first try, I didn't make any changes... and I was surprised that I was able to start the installer with the newly built kernel! No changes and it just works. WTF?

 

Turns out the sources for the kernel do not include the parts for xnu power management. Since it isn't there, it doesn't cause the problem. But of course, AppleIntelCPUPowerManagement expects for PM to be provided by the kernel, so it doesn't work. It doesn't crash, but still no power management. Since 10.8.5 does not have this change, I decided to try the (patched) AppleIntelCPUPowerManagement from 10.8.5 (v214). And that actually works.

 

I don't really like doing rollbacks like that, but it is probably a workable solution until something better comes along. I still think it might be possible to patch the kernel to avoid the MSR writing problem.  See updates below on patches.

 

Update 2013-11-25

 

With some prodding by Pike's blog, I went back to my original patch that I had attempted a number of weeks ago, and I found the mistakes I had made with my patch (this was prior to building the kernel from sources). The details are on my blog here: http://racerrehabman.wordpress.com/2013/11/25/maverickshaswell-kernel-patch-for-early-reboot/

 

As a result, I'm now running a patched mach_kernel (not built from source, but patched from retail), MacBookPro11,2 smbios.plist, AppleIntelCPUPowerManagement.kext, ssdt.aml generated with Pike's script (plugin-type=1). Of course, AppleIntelCPUPowerManagement does not load, as all CPU power management is handled by the kernel (xcpm). In other words, it is running just as a real Haswell MacBookPro would as far as power management. The only "problem" that I can see, is that I'm not getting pstates between x8 and x24, much like the results with iMac14,2. I wonder if something is missing (taking the place of X86PlatformPlugin plists?) that the bootloader/DSDT/SSDT should be injecting to inform the kernel's xcpm behavior? More investigation is needed. I will investigate by watching the behavior of my real MacBookAir6,2 and perhaps a friend's real MacBookPro11,x.

 

Update 2013-11-26

 

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.

 

Update 2013-12-30

 

By borrowing some files from a real Mavericks 10.9.1 install on a real MacBookPro11,2, I was able to achieve states in between idle and nominal:

 

AICPUPMI: CPU P-States [ 8 (17) 24 26 29 30 31 32 33 34 ] GPU P-States [ 17 ]

 

Note new state 17.  This was booting via Clover with MacBookPro11,2 smbios and custom SSDT using ssdtPRgen.sh.

 

In order to do this, I borrowed from the Mac:

/System/Library/CoreServices/PlatformSupport.plist

/System/Library/Extensions/IOPlatformPluginFamily.kext

/mach_kernel (version 13.0.2, patched for xcpm)

 

I'm not sure the kernel replacement was necessary, but I did it anyway.  I think this means that when a future version of OS X arrives that has true support for MacBookPro11,2, things will work a bit better.  I find it interesting that an owner of a a real MacBookPro11,2 cannot do a fresh install of 10.9.1 from the App Store and expect their machine to work as it should.

 

Computer Specifics

HP Envy 15-J063CL (Costco)

i7-4700MQ @2.4Ghz, 12GB RAM

HM87 chipset

HD4600 graphics (1080p panel),

BCM4352 ac WiFi (works with only injection)

RTL8111/8168/8411 (works with RealtekRTL8111)

(I am not certain that I'm keeping this laptop...)

 

Working:

- power management (see pstate results below)

- booting with caches

- HD4600 graphics (this computer uses eDP) (ig-platform-id=0x0a260006)

- HDMI

- USB3 (before *and* after sleep)

- trackpad/keyboard (Synaptics)

- sleep

- sleep triggered by lid

- shutdown/restart

- backlit keyboard on/off (must be hardwired)

- Camera (kind of grainy, but could be poor lighting)

- display brightness (works after display sleep with PNLF DSDT patch)

- works with patched AppleHDA (volume seems low)

 

Not Working/Not Started/In progress

 

Not Tested

- Bluetooth

 

Notes:

- Fixed USB3 after sleep by switching from native AppleUSBXHCI to GenericUSBXHCI with -gux_defer_usb2 flag.

- To avoid strange flicker/flash of display upon boot, make sure to use "Graphics Mode"=1920x1080x32

 

PStates:

 

iMac14,2 (X86PlatformPlugin)

DPCIManager PStates: 8,24,25,26,27,28,29,30,31,32

 

MacBookPro8,3 (ACPI_SMC_PlatformPlugin)

DPCIManager PStates: 8,12,16,20,24,26,28,30,31,32

 

MacBookPro11,2 (xcpm, patched mach_kernel)

DPCIManager PStates: 8,24,25,26,27,29,30,32,33

 

MacBookPro11,2 (xcpm, parts borrowed from real MacBookPro11,2 install):

DPCIManager PStates: 8, 17, 24, 25, 26, 28, 29, 30, 31, 32

 

See my blog for perl patch for mach_kernel.

 

Update 2014-10-18

 

I updated my blog and this post with the patches for the recently released Yosemite 10.10.

 

----

 

For ease of use, I'm providing the patches from my blog here. Please note these patches are only for applying to vanilla mach_kernel, not the "xcpm free" kernel for 10.9 provided as the attachment. The two techniques are mutually exclusive. Either you use "xcpm free" and old school PM, or you use patched kernel and new school (xcpm) PM.

 

 

For 10.10:

perl -pi -e 's|\xe2\x00\x00\x00\x02\x00\x00\x00|\x00\x00\x00\x00\x02\x00\x00\x00|g' kernel
perl -pi -e 's|\xe2\x00\x00\x00\x4c\x00\x00\x00|\x00\x00\x00\x00\x4c\x00\x00\x00|g' kernel
perl -pi -e 's|\xe2\x00\x00\x00\x90\x01\x00\x00|\x00\x00\x00\x00\x90\x01\x00\x00|g' kernel

Please note the kernel resides at /System/Library/Kernels/kernel.

 

For 10.9.x:

perl -pi -e 's|\x74\x6c(\x48\x83\xc7\x28\x90\x8b\x05..\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

For 10.8.5:

perl -pi -e 's|\x74\x69(\x48\x83\xc7\x28\x90\x8b\x05\xfe\xce\x5f\x00\x85\x47\xdc)\x74\x51(\x8b\x4f\xd8\x45\x85\xc0\x74\x05\x44\x39\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\x9c(\x5d\xc3)\x90{7}(\x90{3})|\x74\x70${1}\x74\x58${2}\x75\x4b${3}\x66\x81\xf9\xe2\x00\x74\x02${4}\x75\x95${5}${6}|g' mach_kernel

How to patch your kernel

 

The vanilla mach_kernel is located on your USB installer after creating your USB (with whatever tool you like :-). Here's how to patch it:

 

 

 

 

 

 

 

 

# in Terminal, assuming your USB is called Installer
cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel_backup
cp /Volumes/Installer/mach_kernel ~/Desktop/mach_kernel
cd ~/Desktop
# now copy/paste one or more of the perl patches from above into Terminal
perl ...[from above]... mach_kernel
perl ...[from above]... mach_kernel
# patched mach_kernel is now at ~/Desktop/mach_kernel
sudo cp mach_kernel /Volumes/Installer/mach_kernel

After you install OS X to your HDD, you will have vanilla mach_kernel on the HDD, leading to the same instant reboot problem. So, you must re-enter the OS X installer, and go into Terminal (using Utilities -> Terminal) and replace the mach_kernel with the patched version:

# in Terminal from the OS X installer, assuming your HDD volume is called "Macintosh HD"
cp /mach_kernel "/Volumes/Macintosh HD/mach_kernel"

After that, you can exit the installer, and boot into the installed partition to finish installation and reach the desktop.

 

MD5 sums for mach_kernel

 

Check your md5 sums with:

md5 mach_kernel

10.10 kernel

vanilla: 9f1768fddec369e545d938f0f4f76350

xcpm patched: eb21ca4bd7aba97d5e7b080a481fc173

 

10.9.5 mach_kernel

vanilla: 8f9adba4ca2f55907b8ec8d4bbf4c555

xpcm patched: 0563c5d1fd99db17198d53ad60c9d9ba

 

10.9.4 mach_kernel

vanilla: 3d0ad5a7a8ef3b1d4e6ea33e92e4d3b5

xpcm patched: 921c850e3062e750730b0e99f5eaa381

 

10.9.3 mach_kernel

vanilla: 5ba55b0d446094f82e48e8a413ddfaec

xcpm patched: 6848b1904426d5e270a2db6fada67fb0

 

10.9.2 mach_kernel

vanilla: 15ce54d9b6edc47e282fdf038f71738c

xcpm patched: aeb9203dc754afac23bf9696833032fe

 

10.9 mach_kernel

vanilla: 06b687fa00945c97e06ad1919625793c

xcpm patched: 88bf62a7955b9e20cdb19906bdda6b43

 

10.8.5 mach_kernel

vanilla: e835be83eb956af0b63d28f69bfb22b3

xcpm patched: 539c3a1e2fef063384b44543765b8a39

 

 

DSDT Patches:

 

I have published my DSDT patch project on github. It relies heavily on my generic laptop DSDT patch repo. Read the README.md and setup carefully in order to use.

 

https://github.com/RehabMan/HP-Envy-DSDT-Patch

 

 

10.9 kernel (xcpm free) built from Apple's sources is provided below. Note: DO NOT apply the patches to this attached kernel... they will have no effect. The patches are for vanilla mach_kernel.

 

Update 2014-02-13

Attached mach_kernel built from Apple's sources removed. There is no reason to use it. Use the provided patches to create a mach_kernel that works with machines with locked MSR 0xE2.

[cyf]

I just got the same computer.  Looking forward to trying this!

 

Where can I find the patched AppleIntelCPUPowerManagement?  I searched here and osx86, but couldn't find it.

[RehabMan]

I usually patch it myself with perl script AICPMPatch.pl by el coniglio, but wouldn't a pre-patched one be in Pandora? I really don't know for sure since I don't use the tools here too much.

[styrian]

Hallo RehabMan!

 

For brightness keys working, you could have a look at IOWMIfamily.kext at github Dolnor. It has in sourses a "HPWMI" . At Donovan6000blog :http://donovan6000.blogspot.co.at/2013/08/acpi-controlled-keys.html you can find a compiled version and some hints to make it work on HP.

 

Have you ever done a test like Cinebench 11.5? I am interested on gfx-results of HD4600 and the rendering points of i7 4700MQ.

 

Have fun.

[salvatorepolito]

Can I ask how many P-state are working with your patched kernel and 10.8.5's AICPM ?

Right now there is no way to archive a fully working speedstep on hashwell systems using the new xnu power management. So it could be a solution for us, if it work better.

[RehabMan]

Can I ask how many P-state are working with your patched kernel and 10.8.5's AICPM ?

Right now there is no way to archive a fully working speedstep on hashwell systems using the new xnu power management. So it could be a solution for us, if it work better.

I updated post #1 to include some pstate data.  I tried to build a  MacBookPro11,2 smbios.plist, but was stuck at x8, probably because there is no data in x86platformplugin for that board-id.  At this point, I'm not sure which one is better.

 

With MacBookPro8,3 I reach more states at the lower end (between 8 and 24), but I'm using Sandy Bridge style PM.

With iMac13,2 there is a jump from 8 to 24 (none in between), but using x86platformplugin.

 

Unfortunately there is no data for MacBookPro11,x because those systems use PM in the kernel instead.  Of course, the ideal situation is to somehow patch the kernel to where xmp would work in the kernel just like a real Haswell MacBookPro.

 

At this point, I'm not sure how one or the other affects battery life.  I haven't even put the battery in yet...

Hallo RehabMan!

 

For brightness keys working, you could have a look at IOWMIfamily.kext at github Dolnor. It has in sourses a "HPWMI" . At Donovan6000blog :http://donovan6000.blogspot.co.at/2013/08/acpi-controlled-keys.html you can find a compiled version and some hints to make it work on HP.

 

Have you ever done a test like Cinebench 11.5? I am interested on gfx-results of HD4600 and the rendering points of i7 4700MQ.

 

Have fun.

Thanks I'll check it out.  But right now I have a more fundamental problem: the brightness slider doesn't work in SysPrefs->Displays.  More experimentation/debugging for that later...

Following up on the Cinebench question, using MacBookPro8,3 right now with Sandy PM:

 

Cinebench Resuls, MBP8,3

Cinebench 11.5:

OpenCL: 34.05 fps

CPU: 6.69 pts

 

Cinebench R15:

OpenCL: 20.12 fps

CPU: 609 cb

[salvatorepolito]

With MacBookPro8,3 I reach more states at the lower end (between 8 and 24), but I'm using Sandy Bridge style PM.

With iMac13,2 there is a jump from 8 to 24 (none in between), but using x86platformplugin.

 

Unfortunately there is no data for MacBookPro11,x because those systems use PM in the kernel instead.  Of course, the ideal situation is to somehow patch the kernel to where xmp would work in the kernel just like a real Haswell MacBookPro.

 

At this point, I'm not sure how one or the other affects battery life.  I haven't even put the battery in yet...

 

I read somewhere that on real imacs PM is working in that way. They use only the lowest and the highest P-state and of course Turbo mode. For this reason most people uses mac mini or old mac pro SMBIOS. 

Have you tried MacBook retina SMBIOS ? They come with MountainLion if I remember right and the new PM come after 10.8.5/10.9

 

 

 

[RehabMan]

I read somewhere that on real imacs PM is working in that way. They use only the lowest and the highest P-state and of course Turbo mode. For this reason most people uses mac mini or old mac pro SMBIOS. 

Have you tried MacBook retina SMBIOS ? They come with MountainLion if I remember right and the new PM come after 10.8.5/10.9

Yes, I'm aware of the limited pstates in iMac (it is 'by design' as that's the way real Macs work...)

 

I'm going to try to find out how each of the boardids in x86platformplugin line up with Mac models and see if there is something in there more appropriate. One nice thing (depending on your perspective) about MacBookPro8,3 is that you don't end up with the "Remote Disc" in Finder, as you do on the iMac13,2, probably because the system expects to find a real DVD drive.

[styrian]

@ Rehabman

 

Thanks fore Cinbech results, I have long been looking for. On 11.5  I get with HD4000 since 10 8.4 about 21 fps. Result of HD4600 is really nice (same as 8600 GTS with RampageDev tweaks) and seems by fare good enough to do some photo and video editing tasks. Your results also minimize the for sure surrealistic wish to get dedicated gfx cards besides the Optimus and Enduro (censored) to work on lappies.

 

Thanks.

[salvatorepolito]

Got a KP using your patched kernel and stock AppleIntelCpuPowerManagement.kext

Could not understand why. The expected behavior is an unloaded AICPM because of the new in-kernel PM.

At this point I think that Apple uses the old PM way, maybe on old cpus. But again, why a KP? I mean if there is a whitelist of AICPM supported cpus, this kext should not be loaded on haswell system. 

[RehabMan]

Got a KP using your patched kernel and stock AppleIntelCpuPowerManagement.kext

Could not understand why. The expected behavior is an unloaded AICPM because of the new in-kernel PM.

At this point I think that Apple uses the old PM way, maybe on old cpus. But again, why a KP? I mean if there is a whitelist of AICPM supported cpus, this kext should not be loaded on haswell system.

Read more carefully. This is not a patched kernel. This a kernel built from sources. The sources Apple is publishing *do not* include xcpm. Note that xcpm only applies to systems with Haswell CPUS. If you do not have a Haswell CPU, then you don't need this kernel, but you stil may need patched AppleIntelCPUPowerManagement or patched BIOS (if you can patch your BIOS then you don't need any of this...)

 

So, when using this kernel, AppleIntelCPUPowerManagement *is* loaded. If your BIOS locks the 0xE2 MSR (I suspect it does), then you need a patched AppleIntelCPUPowerManagement.

[salvatorepolito]

Read more carefully. This is not a patched kernel. This a kernel built from sources. The sources Apple is publishing *do not* include xcpm. Note that xcpm only applies to systems with Haswell CPUS. If you do not have a Haswell CPU, then you don't need this kernel, but you stil may need patched AppleIntelCPUPowerManagement or patched BIOS (if you can patch your BIOS then you don't need any of this...)

 

So, when using this kernel, AppleIntelCPUPowerManagement *is* loaded. If your BIOS locks the 0xE2 MSR (I suspect it does), then you need a patched AppleIntelCPUPowerManagement.

Gigabyte's boards are "unlocked", they did not need patched BIOS nor patched AICPM (at least until ML). Maybe what I want to do is not possible. I have an haswell system. And since my board is unlocked I thought It was only necessary your kernel (that has xcpm disabled).

 

[RehabMan]

Gigabyte's boards are "unlocked", they did not need patched BIOS nor patched AICPM (at least until ML). Maybe what I want to do is not possible. I have an haswell system. And since my board is unlocked I thought It was only necessary your kernel (that has xcpm disabled).

It is likely you don't have smbios.plist/ssdt/boot.plist setup correctly.

 

But my understanding is people with unlocked MSRs were having success with xcpm in the kernel...

[salvatorepolito]

But my understanding is people with unlocked MSRs were having success with xcpm in the kernel...

I don't like how xcpm works . Want to try to archive a fully speedstep using old AICPM system.

[RehabMan]

I don't like how xcpm works . Want to try to archive a fully speedstep using old AICPM system.

I see. There are clues about what is wrong in the information printed at KP. There are quite a few variables that must line up:

- proper SSDT for your CPU

- proper smbios

- no cstates/pstates generated from bootloader

- drop OEM SSDTs

- no NullCPU (although that will not cause KP if you forget)

- patched BIOS or patched AppleIntelCPUPowerManagement (or unlocked MSRs in BIOS)

[BaRoN!]

I have this CPU inside my MSI GE60 laptop, was using Atom kernel before. PowerManagement did not worked fine, temperature was always near 88C. Going to try this kernel now, will report how things are going.

I suspect it's offtopic, but anyway - just 2 quick questions: were you able to run vanilla kernel with MacBookAir6,2 smbios? Was your BIOS patched? I was using MacBookAir6,1 and it seems I tried every possible flag combination in Clover, but it kept crashing (I was unable to flush the patched bios, since BIOS update software rejects it). Thanks for the kernel and thanks in advance for answers

[ameris_cyning]

Using this kernel I get a KP with a patched AppleIntelCPUPowerManagement.kext

[RehabMan]

Using this kernel I get a KP with a patched AppleIntelCPUPowerManagement.kext

As I state in post#1, if your BIOS locks the MSRs, you must use patched AppleIntelCPU*.

I have this CPU inside my MSI GE60 laptop, was using Atom kernel before. PowerManagement did not worked fine, temperature was always near 88C. Going to try this kernel now, will report how things are going.

I suspect it's offtopic, but anyway - just 2 quick questions: were you able to run vanilla kernel with MacBookAir6,2 smbios? Was your BIOS patched? I was using MacBookAir6,1 and it seems I tried every possible flag combination in Clover, but it kept crashing (I was unable to flush the patched bios, since BIOS update software rejects it). Thanks for the kernel and thanks in advance for answers

I have not tried MacBookAir6,2. But this laptop cannot run the vanilla kernel because of locked MSRs (thus kernel w/o xcpm). And HP's BIOS is RSA encrypted, so pmpatch is not a possibility.

[ameris_cyning]

As I state in post#1, if your BIOS locks the MSRs, you must use patched AppleIntelCPU*.

 

I have not tried MacBookAir6,2. But this laptop cannot run the vanilla kernel because of locked MSRs (thus kernel w/o xcpm). And HP's BIOS is RSA encrypted, so pmpatch is not a possibility.

 

Are you telling me to patch AppleIntelCPUPowerManagementClient.kext?

[RehabMan]

Are you telling me to patch AppleIntelCPUPowerManagementClient.kext?

No. See post #1.

[ameris_cyning]

No. See post #1.

 

I am not understanding your post

 

I am already using a patched AppleIntelCPUPowerManagement.kext

 

Its giving me a KP

 

Edited November 4, 2013 by ameris_cyning

[RehabMan]

I am not understanding your post

 

I am already using a patched AppleIntelCPUPowerManagement.kext

 

Its giving me a KP

Just saying "I'm getting a KP" is meaningless. Without a photo, I can't give you any ideas. There are other reasons AICPUPM will KP besides MSR lock (bad SSDT, duplicate pstate info, Processor objects missing in DSDT, etc.)

[ameris_cyning]

[RehabMan]

IMG_0045-private.JPG

IMG_0047-private.JPG

You are not crashing in AppleIntelCPUPowerManagement.kext.

 

You are crashing in AppleIntelCPUPowerManagementInfo.kext. That is Pike's replacement for MSRDumper.kext. I suggest you remove it.

[ameris_cyning]

You are not crashing in AppleIntelCPUPowerManagement.kext.

 

You are crashing in AppleIntelCPUPowerManagementInfo.kext. That is Pike's replacement for MSRDumper.kext. I suggest you remove it.

I feel like a {censored} moron

 

You are right.

 

 

It works perfect

 

Damn do I feel like a {censored} fool

HOLY {censored}

 

My temps were at 90+ Celsius

 

And that was idling

 

I was using a iMac14,2 SMBios

 

EDIT 3

 

iMac SMBIOS's only generated one state, 8