Kernel Panic with X86PlatformPlugin using MacBookPro13,3 definition

[dpassmor]

I’m on a Dell XPS 15 9550 using 10.12.3 with a i7-6700HQ, one of the same CPUs present in the new 15" MacBook Pros. If I set the device property 'plugin-type' on CPU0 to 1 with a model identifier of MacBookPro13,3 (which should be correct for my CPU) and the OS loads X86PlatformPlugin, I get a KP. If I use @piker 's freqVectorsEdit.sh to switch to MacBookPro13,2 or MacBook9,1 values I also get a KP. It’s only when I use freqVectorsEdit.sh to switch to MacBookPro13,1 values that the system loads X86PlatformPlugin and boots with no issue.The only real difference I can see is that the MacBookPro13,1 X86PlatformPlugin plist definition lacks these values that are present in MacBookPro13,2, MacBookPro13,3, and MacBook9,1 (extracted from the debug output of freqVectorsEdit.sh):

iocs_engage (20000000), iocs_disengage (15000000), iocs_cstflr (8), iocs_rtrigger (10)

I haven’t had any luck finding out what these are or why they would make a difference. Any ideas?

 

[RehabMan]

I’m on a Dell XPS 15 9550 using 10.12.3 with a i7-6700HQ, one of the same CPUs present in the new 15" MacBook Pros. If I set the device property 'plugin-type' on CPU0 to 1 with a model identifier of MacBookPro13,3 (which should be correct for my CPU) and the OS loads X86PlatformPlugin, I get a KP. If I use @piker 's freqVectorsEdit.sh to switch to MacBookPro13,2 or MacBook9,1 values I also get a KP. It’s only when I use freqVectorsEdit.sh to switch to MacBookPro13,1 values that the system loads X86PlatformPlugin and boots with no issue.The only real difference I can see is that the MacBookPro13,1 X86PlatformPlugin plist definition lacks these values that are present in MacBookPro13,2, MacBookPro13,3, and MacBook9,1 (extracted from the debug output of freqVectorsEdit.sh):

iocs_engage (20000000), iocs_disengage (15000000), iocs_cstflr (8), iocs_rtrigger (10)

I haven’t had any luck finding out what these are or why they would make a difference. Any ideas?

Show photo of the KP.

 

[dpassmor]

Show photo of the KP.

Thanks, here you go. I should note that this happens whether I use the full SSDT generated by ssdtprgen, or just a small SSDT to only set the plugin-type property.

Also I noticed that @piker published an 'xcpm_idle' kernel patch-- I tried it with Clover and it made no difference in my case.

 

[RehabMan]

Thanks, here you go. I should note that this happens whether I use the full SSDT generated by ssdtprgen, or just a small SSDT to only set the plugin-type property.

Also I noticed that @piker published an 'xcpm_idle' kernel patch-- I tried it with Clover and it made no difference in my case.

It is due to locked MSR 0xE2. Code somewhere is writing to MSR 0xE2 (you can see in the panic that RCX=0xE2).
Keep in mind Clover cannot patch a kext unless it is in the cache.
It may not be the xcpm_idle code... there is lots of other code doing wrmsr.

 

[dpassmor]

It is due to locked MSR 0xE2. Code somewhere is writing to MSR 0xE2 (you can see in the panic that RCX=0xE2).
Keep in mind Clover cannot patch a kext unless it is in the cache.
It may not be the xcpm_idle code... there is lots of other code doing wrmsr.

How did you learn this stuff? I dug into the xnu code quite a bit while figuring the Dell SMBIOS stuff out, but not to that level...

The xcpm_idle patch is a kernel patch, the first one I've tried to apply with Clover. I don't know if Clover is actually applying the patch properly since the Clover log doesn't give much feedback, so I will probably try patching the kernel directly and let you know the result.

 

[RehabMan]

How did you learn this stuff? I dug into the xnu code quite a bit while figuring the Dell SMBIOS stuff out, but not to that level...

The xcpm_idle patch is a kernel patch, the first one I've tried to apply with Clover. I don't know if Clover is actually applying the patch properly since the Clover log doesn't give much feedback, so I will probably try patching the kernel directly and let you know the result.

OK... kernel patch should be reliable with Clover KernelToPatch as kernel is always in cache...

 

[dpassmor]

OK... kernel patch should be reliable with Clover KernelToPatch as kernel is always in cache...

Turns out there was a bug in Clover r3994 that inverted the meaning of the 'Disabled' flag for kernel patches, it's been fixed in the svn repo. After building the latest Clover revision, @piker 's patch for xcpm_idle works. I'm now running a MacBookPro13,3 SMBIOS with vanilla X86PlatformPlugin plist for the board, and it's loading X86PlatformPlugin, X86PlatformShim, and all the associated kexts, including AGPMEnabler. It'll be interesting to see what this does for battery life. Thanks for your help!

 

[dpassmor]

An interesting side note: the OS is now fiddling with the HWP_REQUEST register.

Specifically, when the laptop is on AC power, the energy performance preference byte fluctuates to either 0x20 or 0x80. I can't tell if it is correlated to load. When it's on battery, it stays at 0x80.

It is also dynamically changing the desired performance byte on both AC and battery. I've seen values 0x23, 0x1a, 0x1f. It seems to fluctuate between the latter two values when the laptop is idle-ish. The max performance is always set at 0x23, minimum at 0x08, which are correct for my i7-6700HQ. HWP capabilities returns 0x1091A23. Curiously, CPU frequency never drops below 1.3Ghz, where before it would regularly drop to 800Mhz. Geekbench is 4292/13081.

Without injecting plugin-type, the HWP request register stays at the default 0x80002301, and Geekbench is 4149/12607.

 

[RehabMan]

Turns out there was a bug in Clover r3994 that inverted the meaning of the 'Disabled' flag for kernel patches, it's been fixed in the svn repo. After building the latest Clover revision, @piker 's patch for xcpm_idle works. I'm now running a MacBookPro13,3 SMBIOS with vanilla X86PlatformPlugin plist for the board, and it's loading X86PlatformPlugin, X86PlatformShim, and all the associated kexts, including AGPMEnabler. It'll be interesting to see what this does for battery life. Thanks for your help!

An interesting side note: the OS is now fiddling with the HWP_REQUEST register.

Specifically, when the laptop is on AC power, the energy performance preference byte fluctuates to either 0x20 or 0x80. I can't tell if it is correlated to load. When it's on battery, it stays at 0x80.

It is also dynamically changing the desired performance byte on both AC and battery. I've seen values 0x23, 0x1a, 0x1f. It seems to fluctuate between the latter two values when the laptop is idle-ish. The max performance is always set at 0x23, minimum at 0x08, which are correct for my i7-6700HQ. HWP capabilities returns 0x1091A23. Curiously, CPU frequency never drops below 1.3Ghz, where before it would regularly drop to 800Mhz. Geekbench is 4292/13081.

Without injecting plugin-type, the HWP request register stays at the default 0x80002301, and Geekbench is 4149/12607.

Nice findings. Thanks for posting this info.