AppleIntelCPUPowerManagementInfo.kext

Please do NOT download the kext! This version may hang your system! Will update the kext when I located the problem.

A new updated version of AppleIntelCPUPowerManagementInfo.kext is now available for download. I have personally run it on a Sandy Bridge and Haswell configuration and there was no KP. Please try this version and let me know if it works on your hack. Thanks!

Update: The latest version of AppleIntelCPUPowerManagementInfo.kext lets you disable features from the Info.plist See Update-2 below for more info.

Many people already know how handy AppleIntelCPUPowerManagementInfo.kext can be, but the way I compiled the public version made it skip certain parts. Stuff that you may want to see in /var/log/system.log when you are trying to get full power management on your hack going. Or just to check if it is indeed working. This is why I made a new version. One with more output. Here’s the MSR log:

AICPUPMI: MSR_CORE_THREAD_COUNT......(0x35) : 0x40004
AICPUPMI: MSR_PLATFORM_INFO..........(0xCE) : 0x80838F3012200
AICPUPMI: MSR_PMG_CST_CONFIG_CONTROL.(0xE2) : 0x1E000005
AICPUPMI: MSR_PMG_IO_CAPTURE_BASE....(0xE4) : 0x1814
AICPUPMI: IA32_MPERF.................(0xE7) : 0xF7C78F89C
AICPUPMI: IA32_APERF.................(0xE8) : 0xEABEA97E5
AICPUPMI: MSR_FLEX_RATIO.............(0x194) : 0xE0000
AICPUPMI: MSR_IA32_PERF_STATUS.......(0x198) : 0x201300002300
AICPUPMI: MSR_IA32_PERF_CONTROL......(0x199) : 0x2600
AICPUPMI: IA32_CLOCK_MODULATION......(0x19A) : 0x0
AICPUPMI: IA32_THERM_STATUS..........(0x19C) : 0x883A0000
AICPUPMI: IA32_MISC_ENABLES..........(0x1A0) : 0x850089
AICPUPMI: MSR_MISC_PWR_MGMT..........(0x1AA) : 0x1
AICPUPMI: MSR_TURBO_RATIO_LIMIT......(0x1AD) : 0x23242526
AICPUPMI: IA32_ENERGY_PERF_BIAS......(0x1B0) : 0x5
AICPUPMI: MSR_POWER_CTL..............(0x1FC) : 0x4005F
AICPUPMI: MSR_RAPL_POWER_UNIT........(0x606) : 0xA0E03
AICPUPMI: MSR_PKG_POWER_LIMIT........(0x610) : 0xFFD00000EA82
AICPUPMI: MSR_PKG_ENERGY_STATUS......(0x611) : 0x8F048E
AICPUPMI: MSR_PKGC3_IRTL.............(0x60a) : 0x8842
AICPUPMI: MSR_PKGC6_IRTL.............(0x60b) : 0x886A
AICPUPMI: MSR_PKGC7_IRTL.............(0x60c) : 0x8891
AICPUPMI: MSR_PP0_CURRENT_CONFIG.....(0x601) : 0x1F40
AICPUPMI: MSR_PP0_POWER_LIMIT........(0x638) : 0xFFD0
AICPUPMI: MSR_PP0_ENERGY_STATUS......(0x639) : 0x4E19D2
AICPUPMI: MSR_PP0_POLICY.............(0x63a) : 0x0
AICPUPMI: MSR_CONFIG_TDP_NOMINAL.....(0x648) : 0x22
AICPUPMI: MSR_CONFIG_TDP_LEVEL1......(0x649) : 0x0
AICPUPMI: MSR_CONFIG_TDP_LEVEL2......(0x64a) : 0x0
AICPUPMI: MSR_CONFIG_TDP_CONTROL.....(0x64b) : 0x80000000
AICPUPMI: MSR_TURBO_ACTIVATION_RATIO.(0x64c) : 0x0
AICPUPMI: MSR_PKG_C2_RESIDENCY.......(0x60d) : 0x3F280E1392A
AICPUPMI: MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x0
AICPUPMI: MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x0
AICPUPMI: MSR_PKG_C7_RESIDENCY.......(0x3fa) : 0x0

Example of processor info:

AICPUPMI: Low Frequency Mode : 800 MHz
AICPUPMI: Clock Speed : 3400 MHz
AICPUPMI: Max Turbo Frequency: 3800 MHz

Example of IGPU info:

AICPUPMI: IGPU Current Frequency..: 1200 MHz
AICPUPMI: IGPU Min Frequency......: 200 MHz
AICPUPMI: IGPU Max Non-Turbo Freq.: 350 MHz
AICPUPMI: IGPU Max Turbo Frequency: 1200 MHz
AICPUPMI: IGPU Maximum limit......: No Limit

Example of C-State info:

AICPUPMI: CPU C3-Cores [ 0 2 3 ]
AICPUPMI: CPU C7-Cores [ 0 2 3 ]
AICPUPMI: CPU C3-Cores [ 0 1 2 3 ]
AICPUPMI: CPU C7-Cores [ 0 1 2 3 ]
AICPUPMI: CPU C6-Cores [ 0 1 2 3 ]

And yes indeed. This shows you that all processor cores have reached the available C-States. Which is good news. You may wonder why only MSR_PKG_C2_RESIDENCY is being used, but that is most likely something related to the IGPU drivers/settings and I was unable to solve this today (sorry, this was all I could do today).

Example of P-State info:

AICPUPMI: CPU P-States [ 8 17 34 35 36 (37) ] iGPU P-States [ (4) 24 ]
AICPUPMI: CPU P-States [ 8 17 34 (35) 36 37 ] iGPU P-States [ 4 (5) 24 ]
AICPUPMI: CPU P-States [ 8 17 (34) 35 36 37 ] iGPU P-States [ 4 5 (12) 24 ]
AICPUPMI: CPU P-States [ 8 17 34 35 (36) 37 ] iGPU P-States [ 4 5 (10) 12 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 (8) 10 12 24 ]
AICPUPMI: CPU P-States [ 8 (17) 34 35 36 37 ] iGPU P-States [ 4 5 (7) 8 10 12 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 (6) 7 8 10 12 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 (19) 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 (18) 19 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 18 19 (22) 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 18 19 22 (23) 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 18 19 (21) 22 23 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 10 12 (16) 18 19 21 22 23 24 ]
AICPUPMI: CPU P-States [ (8) 17 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 (9) 10 12 16 18 19 21 22 23 24 ]
AICPUPMI: CPU P-States [ 8 17 34 (35) 36 37 ] iGPU P-States [ 4 5 6 7 8 9 10 12 (13) 16 18 19 21 22 23 24 ]

Still not perfect, probably, but it is a lot better already. Anyway. Have fun with it, and let me know if it works for you 😉

Update:
Ok. This is a short run on my i5-4670K:

AICPUPMI: CPU P-States [ 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 (35) 36 37 38 ]

I’d say that is pretty impressive, but this is (currently) only possible with the next update of AppleIntelCPUPowerManagement.kext… if we manage to get it going on a wider range of processor models. This is why your support is so important to us, so please help us validate the kext and data for you processor model. Thank you!

Update-2: The currently available version of AppleIntelCPUPowerManagementInfo.kext lets you disable feature from the Info.plist. For this we have three (boolean) properties:

logMSRs (default value is true)
logIGPU (default value is false)
logCStates (default value is true)

Note: logIGPU is disabled by default because it appears to trigger a KP on certain motherboards. Hopefully these people will help me to fix this problem. Thanks!

Update-3:
MSR_PKG_C7_RESIDENCY is not supported by all processors, and even when it is supported by the processor, then its value can be zero all the time:

Package C6 state is the deepest C-state supported on discrete graphics systems with PCI Express Graphics (PEG).

Package C7 state is the deepest C-state supported on integrated graphics systems (or switchable graphics systems during integrated graphics mode). However, in most configurations, package C6 will be more energy efficient than package C7 state. As a result, package C7 state residency is expected to be very low or zero in most scenarios where the display is enabled. Logic internal to the processor will determine whether package C6 or package C7 state is the most efficient. There is no need to make changes in BIOS or system software to prioritize package C6 state over package C7 state.

Source: Intel datasheet 328897-001.pdf page 58.

Advertisements

Enabling ACPI Debugging

You may have seen something like this in one of your ACPI tables:

Store ("Some text", Debug)

And you may wonder what you need to do to see the debug messages at startup. Well. That is easier than you might expect. And no. You don’t need to install anything. Just add this to: /Library/Preferences/SystemConfiguration/com.apple.Boot.plist

-v debug=0x12a acpi_layer=0x08 acpi_level=0x02

The number one reason for telling you this is that it enables you to check what ACPI Methods in the processor scopes are being called/evaluated.

I did the same and here I only see the debug messages for the following ACPI Methods in the processor scopes: _INI, _PDC, APSS, ACST and _DSM. The latter of course only for CPU0 on Ivy Bridge and Haswell configurations, where we inject a ‘plugin-type’ property, set to 1, to trigger the load of the required plugins. And thus, all other methods in power management related ACPI tables is cruft and can be removed/forgotten.

Oh and here is another tip. The output may scroll too fast, as it did here, but you can stop it by adding Sleep (10000) in the last Processor Scope. This way it waits for 10 seconds before continuing. I also use my iPhone/iPad to film the output.

Note: I am aware of other tools that dump the debug messages, but I love to share anything that may help us. This may not be the best solution for you, but this is what I use today.

Update

Download debugMachKernel.sh and change your boot arguments to:

-v debug=0x12a acpi_layer=0x08 acpi_level=0x02 msgbuf=309212

Reboot and the debug output can be found in: /var/log/system.log or use: sudo dmesg | grep ACPI.

Update-2

With macOS Sierra we only need:

debug=0x12a acpi_layer=0x08 acpi_level=0x02

Reboot and enter:

log show --predicate 'process == "kernel"' --debug --last "5m"

This is everything that you need to do.

MacPro6,1 SMBIOS data

New RevoBoot SMBIOS data:

#define SMB_BIOS_VERSION    "MP61.88Z.0116.B04.1312061508"
#define SMB_PRODUCT_NAME    "MacPro6,1"
#define SMB_BOARD_PRODUCT   "Mac-F60DEB81FF30ACF6"
#define EFI_MODEL_NAME      { 'M', 'a', 'c', 'P', 'r', 'o', '6', ',', '1' }

MacPro61
Other serial numbers can be found here (scroll down to the bottom). Please note that it should begin with: FSKLT.

I checked the SMC _CID in the DSDT and that is the same as what we use for Ivy Bridge and Haswell configurations:

Name (_CID, "smc-huronriver")

Edit: You should set the SMC revision keys in the plist to – data: AiAPAAAW (2.20f16)

The following SMC keys are now also used:

FakeSMCDevice: [Warning] key not found PCTR, length - 2
FakeSMCDevice: [Warning] key not found PG0R, length - 2
FakeSMCDevice: [Warning] key not found PG1R, length - 2
FakeSMCDevice: [Warning] key not found PH0R, length - 2
FakeSMCDevice: [Warning] key not found PMTR, length - 2
FakeSMCDevice: [Warning] key not found PZ2E, length - 4
FakeSMCDevice: [Warning] key not found PZ2F, length - 4
FakeSMCDevice: [Warning] key not found PZ3E, length - 4
FakeSMCDevice: [Warning] key not found PZ3F, length - 4
FakeSMCDevice: [Warning] key not found PZ4E, length - 4
FakeSMCDevice: [Warning] key not found PZ4F, length - 4
FakeSMCDevice: [Warning] key not found PZ5E, length - 4
FakeSMCDevice: [Warning] key not found PZ5F, length - 4
FakeSMCDevice: [Warning] key not found MSAi, length - 2
FakeSMCDevice: [Warning] key not found MSGA, length - 2
FakeSMCDevice: [Warning] key not found WIr0, length - 1
FakeSMCDevice: [Warning] key not found WIw0, length - 1
FakeSMCDevice: [Warning] key not found WIz0, length - 1
FakeSMCDevice: [Warning] key not found TA0V, length - 2
FakeSMCDevice: [Warning] key not found TC0F, length - 2
FakeSMCDevice: [Warning] key not found Te0T, length - 2
FakeSMCDevice: [Warning] key not found TG0F, length - 2
FakeSMCDevice: [Warning] key not found TG0R, length - 2
FakeSMCDevice: [Warning] key not found TG1F, length - 2
FakeSMCDevice: [Warning] key not found TG1R, length - 2
FakeSMCDevice: [Warning] key not found TM0V, length - 2
FakeSMCDevice: [Warning] key not found TS0V, length - 2
FakeSMCDevice: [Warning] key not found Tp0F, length - 2
FakeSMCDevice: [Warning] key not found DM0P, length - 1
FakeSMCDevice: [Warning] key not found DM0S, length - 1
FakeSMCDevice: [Warning] key not found LsNM, length - 1

And then there is this:

SMC::smcReadKeyAction ERROR LsNM kSMCKeyNotFound(0x84) fKeyHashTable=0x0
SMC::smcGetLightshowVers ERROR: smcReadKey LsNM failed (kSMCKeyNotFound)
SMC::smcPublishLightshowVersion ERROR: smcGetLightshowVers failed (kSMCKeyNotFound)
SMC::smcInitHelper ERROR: smcPublishLightshowVersion failed (kSMCKeyNotFound)

This means that Apple will have to update the EFI firmware for other Mac models as well. Pretty soon I hope because that should help solving the error message.

Edit: I solved this by adding a new SMC key to FakeSMC/kext/C*/Info.plist:

<key>LsNM</key>
<array>
    <string>ui8</string>
    <data>AQ==</data>
</array>

This sets it to 1, but the new MacPro has 3. Another related SMC keys is: LsbV (hex_/AQQKAAY=) which I added so that SystemProfiler shows:

Illumination Version: 1.4a6

Oh bummer. Seems like I have even more work to do:

X86PlatformShim::start - Failed to send stepper

Edit: Mac-F60DEB81FF30ACF6.plist does not include FrequencyVectors data, but that appears to be required for Haswell processors. Using Mac-7DF21CB3ED6977E5.plist, or any of the other plist with FrequencyVectors data solved this problem.

Edit: You can download and run freqVectorsEdit.sh to fix the above problem.

Note: I used OS X 10.9.2 Build 13C32 for my testing!

Update:
Using the MacPro6,1 SMBIOS may trigger this error message:
C001 ACST and _CST evaluations failed!
which you can(?) fix by using this AML snippet:

        Method (ACST, 0, NotSerialized)
        {
            Store ("ACST: called", Debug)
            Return (Package (0x05)
            {
                0x01, 
                0x03, 
                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000000, // Address
                            0x01,               // Access Size
                            )
                    }, 

                    0x01, 
                    0x41, 
                    0x03E8
                }, 

                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000010, // Address
                            0x03,               // Access Size
                            )
                    }, 

                    0x03, 
                    0x43, 
                    0x01F4
                }, 

                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000020, // Address
                            0x03,               // Access Size
                            )
                    }, 

                    0x06, 
                    0x46, 
                    0x015E
                }
            })
        }

Which I extracted from the new Mac Pro firmware for you.
Please report when this snippet works for you. Or not of course.

Update-1:

People with a Xeon E5 processor should set the (SMBIOS) cpu-type property to: 0x0A01, 0x0A02 or 0x0A03

OS X Mavericks 10.9.2 Seeded

Apple seeded the first test build of OS X 10.9.2 (13C32) to registered Mac developers, available through the Software Update mechanism in the Mac App Store as well as through the Mac Dev Center.

Everyone else interested in testing OS X 10.9.2 (13C32) without being a registered Mac developer can download OSXUpdCombo10.9.2.pkg with help of: https://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

AppleHDA is still working with my New style of AppleHDA.kext patching, even after being updated to version 2.6.0a12 so that is really good news. But no. I have not checked FaceTime audio. Not yet.

And yes. The Mac Pro images are now available. Finally. Look here.

New style of AppleHDA.kext patching

Someone at work asked me today how I stop AppleHDA.kext from breaking with (almost) every OS update. Okay. This is probably something that most of you here are interested in so let me share that here as well.

The motherboards I use require patched resource files, being layout-3.xml.zlib and Platforms.xml.zlib Nothing new you say. Right. Most people will need patched files, thanks to people like Toleda, but the neat thing is that I trick AppleHDA into loading the resources files from a dummy kext! Yeah. This is something that you won’t find anywhere else, and it took me some time to figure it out, but this is how I did it:

1) sudo cp -R /S*/L*/Extensions/AppleHDA.kext /S*/L*/Extensions/AppleHDA8Series.kext

2) cd /S*/L*/Extensions/AppleHDA8Series.kext/C*

3) sudo rm -R PlugIns

4) sudo rm -R _CodeSignature

5) sudo rm Resources/*.xml.zlib

6) sudo rm -rf Resources/*.lproj

7) sudo rm version.plist

8) sudo cp ~/Desktop/layout-3.xml.zlib Resources/

Note: Change the path/filename so that it points to the file you need for your motherboard!

9) sudo cp ~/Desktop/Platforms.xml.zlib Resources/

Note: Change the path/filename so that it points to the file you need for your motherboard!

10) sudo rm MacOS/AppleHDA

11) sudo ln -s /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA MacOS/AppleHDA

12) sudo nano Info.plist (change version info from: 2.5.3 into: 9.1.1fc1)

13) sudo touch /S*/L*/Extensions

14) sudo reboot now

The trick is simple. OS X will load AppleHDA8Series.kext before AppleHDA.kext due its name and version info, and that basically stops AppleHDA.kext from loading. Then the binary, the one it finds pointed by the symbolic link, is loaded and that in turn loads the resource files from AppleHDA8Series.kext. The binary also loads/fires up the PlugIns from AppleHDA.kext (or AppleHDA8Series.kext if you prefer that).

This way the bootloader can bin-patch the AppleHDA binary on-the-fly, and when required AppleHDAController for HDMI support, or you can simply skip step 10 and 11 and patch AppleHDA8Series.kext/Contents/MacOS/AppleHDA manually, with whatever command line tool you normally use, but please note that you probably need to change path/filename info in (Perl) scripts as it doesn’t know what to use!

People who need to bin-patch AppleHDAController, for example for HDMI support, can run the following additional terminal commands before proceeding with steps 13 and 14:

*) sudo mkdir PlugIns

*) sudo cp -R /S*/L*/Extensions/AppleHDA.kext/C*/P*/AppleHDAController.kext PlugIns/

*) sudo nano PlugIns/AppleHDAController.kext/C*/Info.plist (change version info from: 2.5.3 into: 9.1.1fc1)

Please note that this should only be required when the boot loader cannot bin-patch AppleHDAController for you!

Oh and let me know if this works for you as well. Thanks!

Update:
Oops. I completely forgot to mention that I also add the CodecData in Info.plist as well (under >IOKitPersonalities/HDA Hardware Config Resource) with a changed CFBundleIdentifier (set to com.apple.driver.AppleHDA) or kextutil will complain about it. This way I have everything tidied up in one file.

Note: I set the layout-id property from (EFI) device-properties instead of a ACPI _DSM method.

Update-2:
Someone asked me (per e-mail) if we can use this trick for other kexts as well. But of course you can! That is the whole idea of this new concept, but since AppleHDA.kext patching is something everyone has to deal with… making it a perfect candidate to show you what to do. Have fun now!

Update-3:
You may have found the following message(s) in: /var/log/system.log

Refusing new kext com.apple.driver.AppleHDA, v2.5.3f1: already have prelinked v9.1.1f1.

And when you copied AppleHDAController.kext into AppleHDA8Series.kext/C*/PlugIns then you will also see this message:

Refusing new kext com.apple.driver.AppleHDAController, v2.5.3f1: already have prelinked v9.1.1f1.

Two completely harmless messages. In my view a small price for being able to skip AppleHDA updates. Not to mention that you can copy other kexts like FakeSMC.kext and the one for your network adapter(s) into PlugIns as well. This way you combine several kexts into one. Making one platform specific kext to make updates and re-installations a heck of a lot easier, as all you have to copy is one single kext, but make sure it loads AppleHDA8Series.kext, or whatever it is you use, or your hack won’t even boot anymore!!!

Edit:
This is the XML snippet that I have in: AppleHDA8Series.kext/Contents/Info.plist

		<dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleHDA</string>
			<key>HDAConfigDefault</key>
			<array>
				<dict>
					<key>CodecID</key>
					<integer>283904146</integer>
					<key>ConfigData</key>					<data>IUccECFHHUAhRx4RIUcfASFXHCAhVx0QIVceASFXHwEhZxzwIWcdACFnHgAhZx9AIXcc8CF3HQAhdx4AIXcfQCGHHEAhhx2QIYceoSGHH5AhlxxQIZcdkCGXHoEhlx8CIaccYCGnHTAhpx6BIacfASG3HHAhtx1AIbceISG3HwIh5xyQIecdYSHnHksh5x8BIfcc8CH3HQAh9x4AIfcfQCEXHPAhFx0AIRceACEXH0A=</data>
					<key>FuncGroup</key>
					<integer>1</integer>
					<key>LayoutID</key>
					<integer>3</integer>
				</dict>
			</array>
			<key>IOClass</key>
			<string>AppleHDAHardwareConfigDriver</string>
			<key>IOMatchCategory</key>
			<string>AppleHDAHardwareConfigDriver</string>
			<key>IOProviderClass</key>
			<string>AppleHDAHardwareConfigDriverLoader</string>
			<key>PostConstructionInitialization</key>
			<array>
				<dict>
					<key>CodecID</key>
					<integer>283904146</integer>
					<key>Layouts</key>
					<array>
						<integer>1</integer>
						<integer>2</integer>
						<integer>3</integer>
					</array>
					<key>widgets</key>
					<array>
						<dict>
							<key>MicAttributes</key>
							<integer>28</integer>
							<key>MicInfo</key>
							<string>Sampled on rising edge</string>
							<key>NodeID</key>
							<integer>39</integer>
							<key>PinConfigDefault</key>
							<integer>2426405136</integer>
						</dict>
					</array>
				</dict>
			</array>
		</dict>

Please note that I set the PinConfigurations property from pre-configured (EFI) device-properties in: /Extra/EFI/MacPro61.bin – this is a RevoBoot only feature – simply because setting device-properties from the boot loader is much faster, be it less flexible, but I don’t have to care about that for my setup.

Edit: No. I thought that I did it that way, but apparently not. Oops.

Update-4:
A number of people – Toleda among others – reported that AppleHDAHardwareConfigDriver.kext wasn’t loading, or not at every startup. At first I couldn’t reproduce it myself, but I think to have found a workaround for this, in my view, Apple bug. Here’s what I did:

1) cd /S*/L*/Extensions/AppleHDA8Series.kext/C*

2) sudo mkdir PlugIns (but only in case you don’t already have it)

3) cd PlugIns

4) sudo mkdir -p AppleHDAHardwareConfigDriver.kext/Contents

5) cd AppleHDAHardwareConfigDriver.kext/Contents

6) sudo cp /S*/L*/Extensions/AppleHDA.kext/C*/P*/AppleHDAHardwareConfigDriver.kext/C*/Info.plist .

7) Added the following snippet to the plist:

<dict>
	<key>CodecID</key>
	<integer>283904146</integer>
	<key>ConfigData</key>
	<data>IUccECFHHUAhRx4RIUcfASFXHCAhVx0QIVceASFXHwEhZxzwIWcdACFnHgAhZx9AIXcc8CF3HQAhdx4AIXcfQCGHHEAhhx2QIYceoSGHH5AhlxxQIZcdkCGXHoEhlx8CIaccYCGnHTAhpx6BIacfASG3HHAhtx1AIbceISG3HwIh5xyQIecdYSHnHksh5x8BIfcc8CH3HQAh9x4AIfcfQCEXHPAhFx0AIRceACEXH0A=</data>
	<key>FuncGroup</key>
	<integer>1</integer>
	<key>LayoutID</key>
	<integer>3</integer>
</dict>

Your snippet will most likely be different since ConfigData is missing here, but that is because I set the PinConfigurations property from EFI device-properties.

Edit: No. I thought that I did it that way, but apparently not. I did in fact add the ConfigData there. Like everyone else. Oops.

8) Then I removed all other CodecID related data from the plist and went on with the next step

9) sudo mkdir MacOS

10) cd MacOS

11) sudo ln -s /System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/AppleHDAHardwareConfigDriver.kext/Contents/MacOS/AppleHDAHardwareConfigDriver AppleHDAHardwareConfigDriver

12) sudo touch /S*/L*/Extensions

13) sudo reboot now

What we do here is simple. We use another symbolic link, this time to another binary file, and we copy the Info.plist which we use for our edits.

Edit: If this workaround isn’t working for you, then add a IOProbeScore like so:

<string>AppleHDAHardwareConfigDriverLoader</string>
<key>IOProbeScore</key>
<integer>2000</integer>

Just the two last lines of course 😉

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).

Almost over and out

Hi folks. The year 2013 is nearing the end and that, unfortenately, will also be the end of my involvement. The reason for this is simple; we’re going to have a baby in May (will post a card when our baby is born) but I still need to finish a home for our family.

And this isn’t the only good news. Nope. The concrete slab is finaly ready for the next step, but it was a lot more expensive due to a hidden hole underneath our plot. Which was why it was so darn cheap I guess, but it also means that we now have to pay an extra/unplanned invoice. Think lots of overtime – hence me not having any free time left to play with hack related stuff.

Anyway folks. I hope you all continue your good work and keep it free, like we have been doing for many years. For now:

Merry Christmas and a Happy New Year!