by

OS X Mavericks 10.9.1 Update

Apple released OS X Mavericks 10.9.1 in two flavours being Build 13B42 (243.4 MB) and Build 13B3116 (364.1 MB):

OS X Mavericks 10.9.1 Update
OS X Mavericks 10.9.1 Update for MacBook Pro with Retina Display (Late 2013)

The important thing that you might want to know is that the latter upgrade includes not only a lot more files, including a lot of graphics related kexts, but it also includes later revisions of the files. For example. AppleHDA.kext from the first link is v2.5.3 but the one from the second link is v2.5.8

Also. The mach_kernel is not included with the first one and it lacks updates to XCPM like IOPlatformPluginFamily.kexts where resource files in X86PlatformPlugin.kext are being replaced/added:

Mac-2BD1B31983FE1663.plist – MacBookPro11,3
Mac-3CBD00234E554E41.plist – MacBookPro11,2
Mac-7DF21CB3ED6977E5.plist – MacBookAir6,2
Mac-F60DEB81FF30ACF6.plist – MacPro6,1

A bit odd maybe is that it also includes a fix for the MacBook Air to remedy this message in var/log/system.log

--> Network delay is not specified! Defaulting to 0x384

As in Apple finally added this snippet:

<key>NetworkTimerDelay</key>
<integer>900</integer>

Meaning that you yourself won’t have to edit the kext anymore. Which is great of course. Thanks Apple 😉

It also included the latest plist for the new Mac Pro, which I assume is something people using the new Mac Pro SMBIOS would want to have. But no. The About This Mac image is not included with these upgrades.

And remember this tip. You can download the files by following this link: https://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

Notes:
People who want to install this update should use a SMBIOS from the late 2013 MacBookPro11,n which can be found here but please make a backup first! Before launching the installer. You know. Just in case you run into a problem. Also note that the installer will fail on Build 13A2093 and 13B3116 (as it should).

p.s. Some people are looking for a combo update, but there is no combo update for the first update to OS X as there is nothing to put together (combine).

47 thoughts on “OS X Mavericks 10.9.1 Update”

  2. Just to tell you that I have this error when using SSDTPrGen with 10.9.1
    No problem on 10.9
    i5 4670K on Z87x-OC using clover 2401

    XCPM: registered
    XCPM: P-state table mismatch (error:0x12)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x12
    X86PlatformShim::start – Failed to send PStates

    Reply

    • Ok. I think that this is the same bug as rileyfreeman ran into with his 3930K – the processor data for his CPU in ssdtPRGen.sh was set to 0 (still uninitialised) instead of 1200. Can you please verify this?

      p.s. What is APLF set to?

      Reply

      • I’m sorry Pike for my lack of knowledge… I have tried to do find what you were talking about in vain … hehe. i’m a noob.

        Just wanted to know where do you want me to take a look regarding the processor data and 1200 instead of 0. I have opened ssdtPRGEN.command with Fraise but I don’t think it is coming from here… sorry for being a noob.

        APLF was not set to anything in ssdt.dsl or .aml.
        You asked me put Name (APLF, Zero) I have done it but I had the same problem.

      • Never mind. The data is correct. Already set to 800 MHz. I also have the same processor and I do not see the error you reported. Are you sure that ssdt_pr.aml is loaded? Using the correct name/location? Have you checked it with IORegistryExplorer?

  3. thank you for your feedback
    Just in order to be sure that it correct.

    …..
    Scope (\_PR.CPU0)
    {
    Name (APSN, 0x04)
    Name (APLF, Zero)
    Name (APSS, Package (0x1F)
    {
    …..

    I have add it under CPU0 but same problem
    Don’t know what it has changed. Everything was fine under 10.9 and now it changed and I don’t have Sleep working anymore … lol

    Reply

  4. Yes it is loaded because I Have this different error if I don’t use SSDTPRGEN

    without SSDTPRGEN:
    XCPM: registered
    ACPI_SMC_PlatformPlugin::start – WaitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
    WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3c
    — power management may be incomplete or unsupported

    with SSDTPRGEN:
    XCPM: registered
    XCPM: P-state table mismatch (error:0×12)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0×12
    X86PlatformShim::start – Failed to send PStates

    this error is a very strange one … I must admit

    Reply

  5. I double confirm installed 10.9 again in my other free disk and your SSDT is working correctly using the same BOOT method as 10.9.1 with SSDT included in patched folder of Clover USB starting disk.

    I came to the conclusion that SSDTPrGen has problem with 10.9.1

    Hope all those informations could help you out.

    Reply

      • It is always a good idea to use another boot loader in case something isn’t working. Chameleon/Chimera or RevoBoot. Whatever you pick. Let me know if it solved this mystery.

  6. Pike,

    I have managed to find what was the problem.
    It was coming from my BIOS. I used a modified and updated Bios which is the only way to have my board Stable (Z87x-OC).
    This is what this modified BIOS change
    Intel RAID for SATA 12.7.0.1936
    Intel EFI SataDriver 12.5.0.1815 to 12.7.0.1936
    Intel Boot Agent PXE 1.5.04 to 1.5.48
    Intel GigabitLan X64 5.1.00 to 6.0.24
    Intel PCI Accelerated SVGA PC 2179
    Intel GOPdriver 5.0.1035
    Intel EFI VBIOS 1215 to 6767
    CPU Microcode Pack (with 06C317)
    ME firmware 9.0.30.1482
    Modified splash logo 2

    It probably come from CPU Microcode Pack. It is sad because this modified is greatly updated and is perfectly working with Maverick.
    However it seems that SSDTPrGen is not able to make the correct configuration or maybe it is coming from something else in this new BIOS?…

    Reply

    • I like to see the AppleIntelCPUPowerManagementInfo.kext output of your setup. Have I asked for this already? If not, please download the kext from Tony’s place and run it twice – do a kextload, kextunload and kextload again.

      Reply

  7. THx for the feedback
    Here is the info with modified Bios:l

    ocalhost kernel[0]: AICPUPMI: CPU P-States [ 8 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 34 38 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]
    iMac-de-MMMProd kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 ]
    localhost kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]
    iMac-de-MMMProd kernel[0]: AICPUPMI: CPU P-States [ 34 ]
    iMac-de-MMMProd kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]

    Reply

  8. Pike I have use this command with AICPUMI:
    cat /var/log/system.log | grep “AICPUPMI”

    and I did not got MSR Data. I don’t know what to do.

    Reply

  9. I don’t post what is it before as it is only showing my boot log… no MSR Data. I don’t know why I don’t have any MSR data showing …
    Here is what I have as soon as I load, unload and reload kext
    then trigger the ACPUMI command:

    com.apple.driver.AppleIntelCPUPowerManagementInfo 100009000 is in exception list, allowing to load
    Dec 28 23:00:55 iMac-de-MMMProd kernel[0]: Low Frequency Mode : 800 MHz
    Dec 28 23:00:55 iMac-de-MMMProd kernel[0]: Clock Speed : 3400 MHz
    Dec 28 23:00:55 iMac-de-MMMProd kernel[0]: Max Turbo Frequency: 3400 MHz
    Dec 28 23:00:56 iMac-de-MMMProd kernel[0]: AICPUPMI: CPU P-States [ 34 ]
    Dec 28 23:01:00 iMac-de-MMMProd kernel[0]: **** [IOBluetoothHCIController]
    Dec 28 23:01:01 iMac-de-MMMProd kernel[0]: AICPUPMI: CPU P-States [ 8 34 ]

    Reply

    • Try this: cat /var/log/system.log | grep MSR

      If no MSR data shows up, then do this:

      kextunload /S*/L*/Extensions/AppleIntelCPUPowerManagementInfo.kext
      kextload /S*/L*/Extensions/AppleIntelCPUPowerManagementInfo.kext
      cat /var/log/system.log

      Edit: Oops. The MSR’s won’t be logged because this feature is not enabled in the kext. Only in self compiled versions van it be enabled. Good news. I am already working on a new update so please wait for me to release it.

      Reply

  11. I have the same issue as MMMProd I think.
    10.9.1, iMac13,1 smbios.plist, pmpatched Asus Z77 board, i5-3570K, turbo @ 4100Mhz but no overclock, base clock is 100MHz as you advise. IGPU is disabled.
    All required kexts on your list are loaded.

    I get the error messages from XCPM and X86PlatformShim.
    Latest SSDTprGen sets APLF to 0x08: error 0x12.
    If I change APLF to 0x00: error 0x1a.

    Reply

    • What happens when you set APLF to zero and remove the last eight P-States?

      Failing turbo may be caused by the Ivy Bridge workaround we use (the first/extra Turbo P-State).

      Reply

  12. I don’t know.. you’ll have to tell me exactly what to remove from the SSDT.
    MSRDumper says 6 p-states – HWMonitor confirms this.
    PStatesReached: 16 25 29 34 37 41 🙂

    Reply

    • You said: “i5-3570K, turbo @ 4100Mhz but no overclock” but 41 is the top multiplier so what are you looking for?

      Also. Six P-States may in fact be perfectly valid, but it depends on the model identifier that you are using.

      Reply

  13. No wait, I figured it out myself…there’s no change, except now it says error 13. Same six P-states too.
    I tried to compile your AICPUPMInfo.kext but there are two errors preventing it from compiling. Xcode 5.0.2.

    Reply

  14. 1) I’m blindly looking for the reason why I have xcpm error messages and a way to make them go away. I use iMac13,1

    2) I removed the last eight like you said. Do you want me to remove the first one and the last seven, or the first one and the last eight? 🙂

    Reply

    • First. You say “error messages” (plural) but so far I have only seen one. Is that correct?

      What happens when you only remove the first P-State? Make sure to change the value of APSN from 5 to 4.

      Reply

  15. It’s plural because I meant these, exactly the same as MMMProd:

    XCPM: P-state table mismatch (error:0×12)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0×12
    X86PlatformShim::start – Failed to send PStates

    I only put a single “0x12” or “0x1a” in my description of it above because it’s always the same error code returned in the two first messages. So plural, yes, as there are three error messages in total. 🙂

    I’ll try removing the first P-state and see what happens.

    Reply

  16. Two more things, sorry If I’m being unclear, I’m trying my best.

    In the ssdtPRGen generated SSDT, APSN is not 5, it’s “0x08”, like APFL. What do I change it to?

    The “13” that I mentioned earlier was the error code, does it really have something to do with being “one off from 1200MHz”? I meant 13 as in “XCPM: P-state table mismatch (error:0×13)”.

    Just to make completely sure that I’m understanding you correctly, there are 35 “Package (0x06)” those are the P-states right?

    Reply

  17. I removed the first “Package” without changing anything else:

    XCPM: P-state table mismatch (error:0x4)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x4
    X86PlatformShim::start – Failed to send PStates
    X86PlatformShim::start – Failed to send stepper

    However, I’m still getting the same six p-states either way:
    1/19/14 19:44:23.000 kernel[0]: AICPUPMI: CPU P-States [ 16 25 29 34 37 41 ]
    So what are the error messages about?

    Reply

    • You have 16 (0x1000/1600 MHz) as the lowest P-State and the 0x4 means that you are off four P-States. Remove the last four P-States from the bottom. That should take care of the error message if I am right.

      Then check APSN and make sure that it points to the normal operating frequency of your CPU. Not any of the Turbo frequencies. The next step is to check the value of APLF because that should point to the lowest possible frequency of your CPU, being the P-State where control is set to 0x1000 (1600 MHz).

      Reply

  18. Okay so, from the generated SSDT, remove the first and the last four. Done.
    Both APLF and APSN are 0x08. Not sure what “the control” means but 0x1000 appears in the 26th pstate. Does that mean APFL should be 0x1A? I have no idea.
    Normal operating frequency is 3400MHz. If 1600 is 1000 then 3400 is… no idea either.

    Reply

    • Both APLF and APSN start counting from zero. Not one. So to get the value of APLF you need to look at the lowest possible P-State at the bottom and remember that it starts at 0x00. The next one above that is 0x01 and the above that is 0x02 and so on. This is why it was set to 0x08 ((1600/100)-8=8) but now you have removed P-States and thus you need to make it match again.

      APSN points to the normal non-turbo operating frequency of your processor. In your case that is 3400 MHz so look for the line with: 0x0D48. That is your target. Now change APSN so that it points to this line. This usually equals the number of Turbo P-States, since we humans start counting from one.

      Reply

  19. Oh God…I feel like I should be in a corner drooling and playing with Legos or something.

    I left APLF at 0x08 because I have no idea how to do what you are telling me to do, and set APLF to 0x1A because maybe there may be a slim chance that I guessed right. And I removed the first and the last four P-states.

    XCPM: P-state table mismatch (error:0x1d)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x1d
    X86PlatformShim::start – Failed to send PStates
    X86PlatformShim::start – Failed to send stepper

    Reply

    • Ok. So now you have four extra P-States below your lowest supported frequency and thus it looks like this:

      0x1000 (1600 MHz) APLF = 0x04
      0x0F00 (1500 MHz) APLF = 0x03
      0x0E00 (1400 MHz) APLF = 0x02
      0x0D00 (1300 MHz) APLF = 0x01
      0x0C00 (1200 MHz) APLF = 0x00

      Reply

  20. Okay..thank you..so..APLF…counting from the bottom starting with zero, the one with 1000 is number 4. 0x04. But now you’re messing with my head again, 0x0D48 is in the 23rd package, counting “as a human being”. So that’s 0x17 right?

    Nope…still getting the same messages. This time 0x15.

    XCPM: P-state table mismatch (error:0x15)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x15
    X86PlatformShim::start – Failed to send PStates
    X86PlatformShim::start – Failed to send stepper

    Reply

  21. OK…that makes it 0x07. But XCPM is still not happy….

    XCPM: P-state table mismatch (error:0x11)
    X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
    X86PlatformShim::start – Failed to send PStates
    X86PlatformShim::start – Failed to send stepper

    Reply

    • Ok. Got it. Thanks to ‘Hackmodford‘ on Github issues it is now confirmed to work after removing the extra Turbo P-State at the top and the last eight from the bottom and setting ALPF to Zero. This is why I said:

      “A new error is triggered in OS X 10.9.2 Mavericks (Build 13C32) when you set Name (APLF, Zero) to anything but Zero:

      XCPM: P-state table mismatch (error:0x8)
      X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x8
      X86PlatformShim::start – Failed to send PStates      ”

      Here: https://pikeralpha.wordpress.com/2013/10/05/xnu-cpu-power-management/

      It would be nice if you can make the same changes and then also confirm this to work. I’ll update ssdtPRGen.sh I only need to figure out in what version of OS X this changed.

      Reply

Leave a comment