Have to leave again

Shit hey. I need to leave right away. Grandma is really going backwards with her health. Later folks!


We are going to bring grandma home, to Holland, for the last time. It is over and out for her, she’s too old and too sick to stay behind. Mom is going to take care of her now.

SMC The place to be, definitely!

Now that we have a patch to stop XCPM in the Mavericks mach_kernel rebooting your hack, thanks to RehabMan for all testing, I now like to propose something entirely different. This time I am on slippery ice… because we promised not to work on SMC code/hacks. And I won’t break this promise, but I hope that the FakeSMC developers will see the light. That what they have been saying all these years. That this error is a non-issue… is not true:

SMC::smcInitHelper ERROR: MMIO regMap == NULL – fall back to old SMC mode

My understanding of things is that you see this error just because something is not right. Something need to be done differently. First. Have a look at the following ACPI snippet from a late 2013 iMac (iMac14,2):

Device (SMC)
    Name (_HID, EisaId ("APP0001"))  // _HID: Hardware ID
    Name (_CID, "smc-huronriver")  // _CID: Compatible ID
    Name (_STA, 0x0B)  // _STA: Status
    Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        IO (Decode16,
            0x0300,             // Range Minimum
            0x0300,             // Range Maximum
            0x01,               // Alignment
            0x20,               // Length
        Memory32Fixed (ReadWrite,
                       0xFEF00000,         // Address Base
                       0x00010000,         // Address Length
        IRQNoFlags () {6}

Now look at this ACPI snippet:

    OperationRegion (PLMT, SystemIO, 0x0310, 0x0A)
    Field (PLMT, WordAcc, Lock, Preserve)
        CPLT,   8,
        IGPS,   8,
        MPLT,   8,
        CFIL,   8,
        EGPS,   8

Who here remembers Samantha’s blog article about it? Right. These are the CPU, IGPU, Memory and EGPU P-State limits. Oh and sorry because I can’t recall the meaning of CFIL right now, thus I will have to dig it up for you at a later time.

Anyway. Note the Memory32Fixed in the first ACPI snippet, because that part is missing in FakeSMC. This 64 KB data window is empty in your hack. But why don’t we use what Apple is providing?

Never wondered what’s inside of all these SMC updates? I tell you this; I certainly looked at them. That is also where the blog title is coming from, because that is literally part of the SMC update PKG’s.

Sure. I first had to write a script to convert the data to a binary format and then I opened it with HexEdit. Hmmm. Ok. So the file is longer than the 64 KW address space defined in the DSDT, but look at the EFI binary that writes the data. Right. Another problem. Nobody ever disassembled the EFI binary, of course, otherwise this would have been a real non-issue… instead of telling people that the error is DUST 🙂

Experimental bin patch for Maverick

Some people are experiencing a reboot with Mavericks, because XCPM (read: mach_kernel power management) writes to a locked register (bit 15 of MSR 0xE2 is set) and that is why I looked at the disassembled code of the mach_kernel (the XCPM source code is still not released by Apple) and I found a routine that we might have to change a little. Here it is:

    +0  ffffff80002d5ad0  89f9                      movl        %edi,                         %ecx
    +2  ffffff80002d5ad2  89f0                      movl        %esi,                         %eax
    +4  ffffff80002d5ad4  48c1ee20                  shrq        $0x20,                        %rsi
    +8  ffffff80002d5ad8  89f2                      movl        %esi,                         %edx
   +10  ffffff80002d5ada  0f30                      wrmsr
   +12  ffffff80002d5adc  31c0                      xorl        %eax,                         %eax
   +14  ffffff80002d5ade  c3                        ret
   +15  ffffff80002d5adf  b801000000                movl        $0x1,                         %eax
   +20  ffffff80002d5ae4  c3                        ret

This routine might be used by calls to wrmsr and thus I like to propose a small change to see if I am right. Or not of course. Anyway. Change the 0f30 into 9090 and see if that stops it from rebooting.

If this change stops it from rebooting, then we can come up with something that filters out MSR 0xE2 (_xcpm_core_scope_msrs) and do what we want it to do. Otherwise we may try to change the value of _xcpm_core_scope_msrs (0xE2) into something like 0xC3 (for example). For this you have to search for:

E2 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 07 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E2 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 05 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E2 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 08 00 00 7E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then you change the value E2 (in red) into C3. Let me know if this works or not. Thanks!


I did not mention the assembler code that uses this data, simply because if I have to tell people that then they probably don’t even know what to do with it, but trust me… I certainly know what is calling it.


The values in blue are stored into the MSR (0xE2) but only one is used and the value depends on the SKU (processor model). We know this because the output of AppleIntelCPUPowerManagementInfo.kext of a MacBookAir6,2 shows us that it is set to 0x7E000008 and my desktop processor uses the second block, which I know because I changed the value from 0x1E000005 to 0x1E000007 and that now shows up in the output of AppleIntelCPUPowerManagementInfo.kext In other words. We should only have to change one block. Not all three.


I did some more testing and have tried setting bit-1 of MSR 0x1AA (MSR_MISC_PWR_MGMT) with RevoBoot, but then even my Gigabyte desktop board reboots. Pretty interesting.

Also. _xcpm_cpu_model_get is called from _xcpm_perf_bias_set (jmpq 0xffffff80002f9ba0) and thus you can eliminate the initialisation altogether by nop’ing it out (falling back to AppleIntelCPUPowerManagement.kext for supported processors) but I would much rather have a patch that only skips the MSR that triggers the reboot. In short: Is this bit (1) the problematic one?


Cool. This is no longer an issue. RehabMan confirmed that the first patch will not work, but my second proposal does – he worked out a patch so now people with a locked (UEFI) BIOS can boot Mavericks… with the vanilla stock mach_kernel. All you need now is a boot loader that can patch the kernel, or patch the mach_kernel manually.

Thanks to RehabMan for all testing and coming up with a patch, even if I would have done it a little differently – see comments (there are many roads to Rome, but as long as one brings you to Rome… then I am fine with it 😉


Just for the record; You only need to patch the mach_kernel when it reboots due to a locked MSR (0xE2) and if PMPatch (by CodeRush) isn’t working for you or when you don’t want to/can use it, but all other people should check this out.