[Guide] How to install Yosemite using Unibeast

Overview

One of the first challenges you'll face in installing OS X to your laptop will involve getting the OS X installer to boot from USB. I'm not going to provide a step-by-step guide on how to use Unibeast. That is described in the main guide: http://www.tonymacx86.com/445-unibea...-based-pc.html. But I will cover some of the flags needed to boot common laptop configurations (Intel and dual-GPU Intel/other)

Realize that booting the OS X installer involves booting OS X on your laptop! Because the OS X installer runs under OS X. So, solving problems booting the installer are actually bringing you closer to running OS X after it is installed.


Know your hardware

There is almost no chance of success if you don't know the main components inside your laptop. And when asking for help, the critical components should be listed in your profile.

This guide is primarly focused on Intel or Intel+Nvidia or Intel+AMD. Personally, I don't have any Radeon or Nvidia hardware, so I don't know much about booting the installer on those systems.

I will write this response to anyone who doesn't have the details in their profile:

Please provide complete details in your profile/signature
(Profile/Settings link in upper right corner of this site)

System: manufacturer/model
CPU: detailed CPU model + motherboard chipset
Graphics: all graphics devices + laptop internal screen resolution

For example, typical Ivy laptop:
System: HP ProBook 4540s
CPU: i5-3320m/HM76
Graphics: HD4000, 1366x768

Use CPU-Z on Windows to find CPU (Core iX-xxx) and motherboard chipset (HMxx), and graphics capabilities. For a laptop, these details are important and affect critical installation procedures.

Obviously, you can use programs other than CPU-Z, but it does work for four of the five details above. And your screen resolution is easily discovered from graphics properties on Windows. Please do everyone a favor and update your profile prior to asking a question.


Creating the USB

Make sure you created your USB with "Laptop Support" and without "Legacy USB"

Remove /Extra/Extensions/AppleACPIPlatform.kext
Update VoodooPS2Controller.kext at /Extra/Extensions on the USB: https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller
Add GenericUSBXHCI.kext to /Extra/Extensions on the USB: https://github.com/RehabMan/OS-X-Generic-USB3

Note: Adding GenericUSBXHCI.kext is optional. If your laptop happens to work natively with AppleUSBXHCI.kext or does not have USB3, then it would be unnecessary.

Note: Please READ the README at each link so you know where pre-built binaries are located.

Unibeast automatically installs Chimera to the USB. If you need Chameleon, you would have to install it after preparing the USB with Unibeast.


FakeSMC

FakeSMC is automatically installed to your USB by Unibeast.

But if you run into a situation where you see: "Waiting for DSMOS" without a corresponding "DSMOS has arrived" later in the bootlog, you have an issue with FakeSMC. Either it is not loading or not starting.


Verbose boot

You should use -v to boot verbose, so you can see what is going on behind the scenes. If you don't use verbose boot, and the boot process should stop, there's no sense of why. So, no matter what flags you need to type, you should always use -v until you know the particular combination of flags that works for your hardware.

If you run into an issue booting the installer, capture a photo, or series of photos so the problem can be diagnosed. Always capture the entire screen with enough quality that the text can be read. Don't assume the last message logged is the most important (it almost always is not).

Realize also that booting the OS X installer from USB is quite slow. Don't give up on it too soon. It is possible to have up to two-minute pauses where nothing changes on screen.


dart=0 and VT-d

Kernel flag dart=0 should be used when your CPU has VT-d and you cannot disable it in BIOS. Most laptop BIOS implementations are limited and do not allow you do disable it. If you're not sure, just use it anyway, as there seems to be no harm in using it when it is not necessary.


Haswell early reboot due to locked MSR 0xE2

If you have a Haswell CPU and experience a reboot just after starting the kernel, it is likely XCPM panic due to locked CPU MSR 0xE2.

With Chameleon/Chimera, you will need to patch the kernel, both on the USB and your final HDD install.

See here for details: http://www.tonymacx86.com/yosemite-l...ly-reboot.html


Local APIC panic

If you get a kernel panic "Local APIC" (lapic) panic, your interrupt controller is not set the way OS X expects. Lapic panic does not always stop the boot process, so you need to keep your eyes open for it. Also, it can cause a reboot early in the boot process (just as XCPM/Haswell early reboot). You will need to use cpus=1 and later install the KernelPatcher module from Chameleon Wizard so you can boot without cpus=1.


USB Problems

You're attempting to boot OS X from USB. At some point, the system needs to mount root (/) to your USB. If the USB drivers are not able to load and initialize the USB ports, the system will not be able to mount root and will not be able to boot.

Usually, the USB errors are apparent in the verbose log when this happens.

Boot with USBBusFix=Yes in this scenario. You may find EHCIhard=Yes and EHCIacquire=Yes also useful (although USBBusFix is supposed to encompass both). Also, USBLegacyOff=Yes can be useful. If your BIOS has options for USB you should experiment with them.


ACPI Problems

Some OEM SSDT tables can cause problems. You can disable these SSDTs (known as "dropping") with DropSSDT=Yes.


Graphics Problems

Most problems stem from graphics configuration problems. Often, a graphics issue will be mistaken for a bluetooth issue, only because on a successful boot, the bluetooth messages are one some the last to appear. A successful boot with a graphics issue (no framebuffer loaded, or a hung framebuffer), ends with bluetooth messages. Removing bluetooth kexts will not help. The solution is to provide the correct set of flags or other configuration to make the Intel graphics work.

If you are unable to activate the internal display, try plugging in an HDMI monitor as a temporary solution. Since you'll likely run into the same problem post-install, it will still remain a problem to solve.


Arrandale/1st gen Intel HD

First generation Intel HD graphics are not well supported, and as far as I know it is not possible to boot the installer without removing the Intel graphics kexts (AppleIntelSNB*, AppleIntelHD*, AppleIntelFrame*).

See this link for more information: http://www.insanelymac.com/forum/top...graphics-qeci/


Sandy Bridge/HD3000/6-series chipset/low resolution

If your display is 1366x768, Chimera should be able to boot with working a working HD3000 graphics without any special graphics flags (just IGPEnabler=Yes, which is default on the Unibeast created USB). If your display is higher resolution (1600x900 or 1920x1080), then it is likely your laptop uses a dual-link display. In this case, you must pre-patch DSDT in order to inject AAPL,DualLink.

So for, Chimera, no special flags are generally required for HD3000 graphics.

With Chameleon, you will likely need: GraphicsEnabler=Yes

If you still have trouble, you should pre-patch DSDT...

HD3000 Low Resolution: https://github.com/RehabMan/Laptop-DSDT-Patch
Apply: 
"HD3000 Low Resolution"


Sandy Bridge/HD3000/6-series chipset/high resolution

If your display is higher resolution (1600x900 or 1920x1080), then it is likely your laptop uses a dual-link display. In this case, you must pre-patch DSDT in order to inject AAPL,DualLink.

You will need to patch DSDT in order to reach the installer because of the duallink display.

Extract native DSDT with Linux (/sys/firmware/acpi/tables/) or Windows (RW-Everything).

HD3000 High Resolution: https://github.com/RehabMan/Laptop-DSDT-Patch
Apply: 
"HD3000 High Resolution"

Place at /Extra/dsdt.aml after creating your USB and for your final install.


Ivy Bridge/HD4000/7-series chipset/low resolution

Similar to the HD3000/1366 case, you can usually boot without flags using Chimera3 and Chimera4.

With Chameleon, use: IntelCapriFB=3 GraphicsEnabler=Yes


Ivy Bridge/HD4000/7-series chipset/high resolution

For 1600x900 and 1920x1080, you will need to inject a different ig-platform-id than is default.

Chimera: Most HD4000 high resolution systems respond well with IGPlatformID=01660004. Note that HDMI does not work with 01660004 (requires kext patches). Alternates are IGPlatformID=01660008 and IGPlatformID=01660009. And, of course, 01660003 can be used in a pinch with an HDMI monitor.

More information: Chimera HD Graphics Bootflags: IGPEnabler, IGPlatformID, and IGPDeviceID

Chameleon: Use GraphicsEnabler=Yes IntelCapriFB=4. Alternate values for IntelCapriFB are 4, 8, and 9.

More information: http://www.insanelymac.com/forum/top...g-platform-id/


Haswell HD4200/HD4400/HD5000/HD5200

These Haswell graphics devices are recognized natively by the Yosemite graphics drivers. As a result, it is necessary to inject the correct ig-platform-id that works with your laptop. Sometimes finding the right ig-platform-id can involve trial and error. For most laptops, much like in Mavericks, ig-platform-id = 0xa260006 works.

For Chimera, the default is 0A260006. You can change it with bootflag IGPlatformID.

Chameleon: Use GraphicsEnabler=Yes InjectIntel-ig=aabbccdd, where aabbccdd is a byte-reversed value for ig-platform-id.

For example, if you want to try 0a260005, use InjectIntel-ig=0500260a

Some common mobile Haswell ig-platform-id values are: 0a260006, 0a260005, 0a260000, 0a160000, 0a2e0008, 0a2e000a


Haswell HD4600

With HD4600 and Yosemite, you should be able to reach the installer without injecting an ig-platform-id value. This is because HD4600 is not recognized by the HD5000/Azul kexts anymore (a change from Mavericks). The installer, therefore, is expected to run with base/VESA drivers.

Post install, you'll need to do some patching to enable HD4600 QE/CI. See here for details:http://www.tonymacx86.com/yosemite-l...-yosemite.html


Mixed Systems

If you have an Ivy CPU with a 6-series board (rare) or a Sandy CPU with a 7-series board (not as rare), you will probably have difficulty reaching the installer even if you provide the correct ig-platform-id. This is because the graphics drivers are dependent also on the driver for the Intel MEI device. The way Apple has factored these drivers does not allow for a mixed system because the MEI driver for 6-series boards is in the same kext as for HD3000, and the MEI driver for 7-series baords is in the same kext as for HD4000. It is not possible to load the framebuffer for HD4000 to get the MEI for a 7-series board when you have HD3000 on a 7-series board. Similarly, it is not possible to load the framebuffer for HD3000 to get the MEI for a 6-series board when you have HD4000 on a 6-series board.

In order to account for this problem, the Info.plist files need to be modified so that the 6-series MEI loads when you have HD3000 on 7-series, and 7-series MEI loads when you have HD4000 on 6-series. If you're thinking this is a bit sketchy you'd be right. It should be obvious that the driver for 7-series MEI may not work properly with the 6-series MEI device, and similarly, that the driver for 6-series MEI may not work properly for the 7-series MEI device. Perhaps there is some instabilty caused by this, but it does seem to work. The problem with Info.plist patches is that they can be overwritten by system updates. It is better, then, to use DSDT patches instead.

Having a mismatch will cause the graphics drivers to hang (or is a very long delay). You will also see verbose logs about duplicate kexts and the inability to load HDCPCtrl because of these duplicates.

To work around this problem, we use DSDT patches to inject the device-id of the correct MEI device for the graphics driver that will be in use.

Extract native DSDT with Linux (/sys/firmware/acpi/tables/DSDT) or Windows (RW-Everything).

HD4000 on 6-series: https://github.com/RehabMan/Laptop-DSDT-Patch
Apply: "HD4000 on 6-series"

HD3000 on 7-series: https://github.com/RehabMan/Laptop-DSDT-Patch
Apply: "HD3000 on 7-series"

Note: Please read the README so you know how to use MaciASL and the laptop DSDT patch repository.

Place at /Extra/dsdt.aml after creating your USB. And for your final install.

Note that if you had HD3000 on 7-series with a high resolution display, you would need to do both the patch previously mentioned for "HD3000 High Resolution" and for "HD3000 on 7-series"


Ultra High Resolution/QHD

Some of the high end laptops are coming with QHD+ displays. These displays pose a problem for OS X as it artificially limits the pixel clock.

Getting it to work involves patching the framebuffer, patching some framework code, and potentially flashing a patched BIOS.

[Guide] Patching DSDT/SSDT for LAPTOP backlight control

Overview

Note: This guide is primarily for Intel HD graphics (HD3000->HD5000+). Although some of the kexts and patches mentioned here can be used in other scenarios, that is not the focus of this post.

By default, your non-Apple DSDT does not have the necessary trigger to cause AppleBacklight.kext to load. Although it is easy to make it load by adding a PNLF device (aka "Brightness Fix" from my laptop repo), it will likely not work correctly. It may not work at all prior to sleep, and even after sleep the full range of brightness will not be available. This is becuase AppleBacklight.kext only has profiles for panels that appear in actual Apple products and there can be PWM registers that are not initialized by BIOS as OS X expects.

A slightly modified DSDT patch can correct for the problem before sleep, and the issue of full range can be fixed by patching AppleBacklight.kext (or providing an injector kext that does the same thing), or by patching EDID. But still, smooth transitions when using keyboard controls will not work (reason not known).

A complete solution to the problem can be achieved with ACPIBacklight.kext and a more complex DSDT patch.

In order to implement brightness you must have working graphics drivers (QE/CI), and you must be using a laptop snb-platorm-id/ig-platform-id. Brightness controls are available only for internal LVDS displays.


DSDT/SSDT patching

There are two different DSDT patches available. One for pre-Haswell (Arrandale, Sandy Bridge/HD3000, Ivy Bridge/HD4000) and one for Haswell (HD4400/HD4600/HD5000+).

You should follow the general guidelines for DSDT patching as presented here: [Guide] Patching LAPTOP DSDT/SSDTs

The patches are available here: https://github.com/RehabMan/Laptop-DSDT-Patch

pre-Haswell: "Brightness Fix (HD3000/HD4000)"
Haswell: "Brightness Fix (Haswell)"

Apply only the brightness patch that applies to your hardware. The patch must be applied to the the file (DSDT or SSDT) where the integrated graphics device is defined. Intel hardware is always at address 0x00020000. Searching for "Name (_ADR, 0x00020000)" is a way to find the device. It is commonly called GFX0, so searching for "Device (GFX0)" is also an effective search most of the time.

The patch will only apply to the file where it finds the device at 0x0002000.

Note: By setting LMAX to Zero, you can cause the patch to use BIOS register values at boot. This can eliminate an extra flash at boot time and may be better for some laptops (the _BCL table is automatically scaled as required).


ACPIBacklight.kext

For complete brightness control including smooth transitions, you need to install ACPIBacklight.kext.

It is available here: https://github.com/RehabMan/OS-X-ACPI-Backlight


IGPU power management

It is common to fix power management for the IGPU at the same time as applying brightness. To implement IGPU PM, apply "Rename GFX0 to IGPU" to DSDT and all patched SSDTs. Failure to apply it universally will likely cause one or more SSDTs to be ignored.

Note: Older versions of the patch required this patch, but newer versions do not have that restriction. IGPU power management is still worthwhile to implement.


Backlight troubleshooting

After installing ACPIBacklight.kext rebooting with the brightness patch in place,you should have an operational brightness slider in SysPrefs->Displays. Keyboard control over backlight is a separate issue.

If your backlight control is not working, it could be due to one or more issues:
- incorrect patch applied
- a previous PNLF patch has been applied to DSDT
- Clover is providing PNLF in DSDT (avoid AddPNLF in ACPI/DSDT/Fixes)
- you forgot to drop OEM SSDTs (Clover: ACPI/SSDT/DropOem=true; Chameleon DropSSDT=Yes)
- renames were not balanced causing OS X to ignore one or more SSDTs
- there are duplicate _DSM methods causing OS X to ignore one or more SSDTs
- your DSDT/SSDTs are out-of-sync with your native DSDT/SSDTs files
- you have not disabled a secondary discrete graphics card in a switched configuration
- your hardware does not use the IGPU PWM backlight controls

To determine if your hardware uses the PWM backlight controls, temporarily remove ACPIBacklight.kext to use AppleBacklight.kext. If the brightness slider in SysPrefs->Displays works (check both before and after display sleep), then your laptop uses the backlight registers and the cause is one of the others mentioned above. 

If it does not work, then your laptop doesn't use the backlight registers. In that case, try "Brightness Fix", which will cause ACPIBacklight.kext to use the OEM methods (most of the time, the OEM methods do not work). If your OEM methods actually work (with "Brightness Fix"), you may be able to use "Brigthness Fix (ACPI 100)" for smoother transitions and more backlight levels.

It is quite common for ACPIBacklight.kext (and the DSDT patches discussed here) to not work unless you disable the discrete card on switched dual-GPU configurations. Done in BIOS or via DSDT/SSDT patches.


Brightness Keys

The brightness patch will only enable the slider in SysPrefs->Displays. Keyboard control is a separate issue, as the keyboard driver must generate the special codes used to trigger the OS X native backlight controls.

Your brightness keys (usually one of the Fn+F1...F12 keys) may be handled with PS2 or ACPI. Most newer computers use ACPI for these keys. If your trackpad is Synaptics and you're using my fork VoodooPS2Controller.kext (https://github.com/RehabMan/OS-X-Voodoo-PS2-Controller), you can make either case work.

The first step is to determine if they are handled by PS2 or ACPI. With my driver, you can use 'ioio -s ApplePS2Keyboard LogScanCodes 1' to turn on the key logging to system.log. The ioio binary is available here: https://github.com/RehabMan/OS-X-ioio (please read the README for download locations). After turning on key logging, monitor system.log with Console.app to determine what PS2 codes (if any) are generated when you press your keys). If they generate PS2 codes, you can map them to backlight control by following the wiki: https://github.com/RehabMan/OS-X-Voo...yboard-Mapping.

If your keys do not generate PS2 codes, it is likely they generate ACPI events. In order to intercept the ACPI events, you will need to determine which method(s) are called when the keys are pressed. Usually, media keys generate EC queries. A simple strategy is to use ACPIDebug.kext to instrument all EC query methods, then press the keys while monitoring system.log. When you press the keys, the name of the method will be output, which will allow you to patch that method.

Determining EC query methods:

- install ACPIDebug.kext: https://github.com/RehabMan/OS-X-ACPI-Debug
- add the ACPIDebug repo to MaciASL "Sources" per README
- apply ""Add DSDT Debug Methods"
- apply "Instrument EC Queries"
- reboot
- monitor system.log as you press your brightness keys

After you have determined which methods correspond to the brightness keys, you can patch the methods...

Assuming _Q10 is brightness down, and _Q11 is up.

Code:

into method label _Q10 replace_content
begin
// Brightness Down\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
end;
into method label _Q11 replace_content
begin
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
end;

The 0x0205/0x0285 corresponds to PS2 keydown/keyup (e005/e085) for the brightness down key used by Dell laptops. In the default keyboard profile, these correspond to ADB codes 91/90 (brigthness down/up). If your laptop uses a keyboard profile other than the default, you may need to use different codes.

It is possible for both keys (up/down) to generate a call to the same EC query method. This is the case with the Haswell HP Envy, for example. By examining the code it is possible to determine how to disambiguate. As it turns out a variable in the EC is set to indicate the function to be performed when the _Q13 method is invoked. The patch for this case is as follows:

Code:

into method label _Q13 replace_content
begin
Store(HKNO, Local0)\n
If (LEqual(Local0,7))\n
{\n
// Brightness Down\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0205)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0285)\n
}\n
If (LEqual(Local0,8))\n
{\n
// Brightness Up\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0206)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x0286)\n
}\n
If (LEqual(Local0,4))\n
{\n
// Mirror toggle\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x026e)\n
    Notify(\_SB.PCI0.LPCB.PS2K, 0x02ee)\n
}\n
end;

Of course, this code is based on the original code in the DSDT for the HP Haswell Envy. It is likely the details for disambiguation in your DSDT differs. You need to read the original code and make the adjustments to the replacement code as necessary.

Note: This patch also includes support for the "mirror toggle" function, where the standard PS2 code is 0e6e/0eee (make/break).

Note on ELAN (and other) drivers

If you are using another keyboard driver, instead of sending notifications to the PS2 object, you can send them to an object attached to ACPIKeyboard.kext The process is very similar to the process as written above (for ACPI), and is covered well at the ACPIKeyboard github README. See here:https://github.com/RehabMan/OS-X-ACPI-Keyboard

[Guide] Native Power Management for Laptops

Overview

Power Management should be one of the first things implemented when trying to install OS X on a laptop. Because of heat/noise and battery life issues, using NullCPUPowerManagement is not a realistic option on a laptop. This guide will start assuming you are running Multibeast for the first time and wish to implement power management on a laptop with a Sandy Bridge, Ivy Bridge CPU, or Haswell CPU.

Make sure you download and use the latest version of Multibeast. Most laptops have locked CPU MSRs so you need a patched AppleIntelCPUPowerManagement.kext to avoid a KP upon boot. In fact, you just watch for updates to the system that might replace this kext and be sure to replace it with a patched version before rebooting following the update. Some laptops can flash a patched BIOS to avoid this problem, but I do not recommend it. Why risk bricking your laptop with a patched BIOS when a simple software change can accomplish the same thing?

You should be aware of what kind of CPU you have. A Sandy Bridge CPU will be Core iX-2xxx[U|M|QM]. An Ivy Bridge CPU will be a Core iX-3xxx[U|M|QM], and Haswell Core iX-4xxx[U|M|QM]. Know what the exact CPU is in your laptop and provide it in your profile. Just saying "I have a laptop with an i5" is not helpful.

Most of this guide's specifics are concerning Chameleon/Chimera bootloader configuration. If you're using Clover, the same concepts apply, but the details are different. Clover differences are covered at the end of the post.

First run of Multibeast (make sure you are using the latest version) select the following options:

- UserDSDT or DSDT-Free Installation
- Sandy/Ivy only: Drivers & Bootloaders -> Drivers -> System -> Patched AppleIntelCPUPowerManagement. With Haswell patched AICPUPM is not necessary, since PM is handled in the kernel instead. And, of course, you already had to patch mach_kernel to even make it this far.
(be sure to select the version appropriate for the version of OS X you have installed)

Note: If you have a laptop subject to "Local APIC panic" (HP consumer laptops, for example), you should install the KernelPatcher module from Chameleon to /Extra/modules. The KernelPatcher module is available from Chameleon Wizard and the Chameleon package installer.

Choosing an SMBIOS

If you have a laptop with Sandy Bridge CPU use Multibeast's Customization -> System Definitions -> MacBookPro8,1.

If you have an Ivy Bridge CPU, you should obtain/create an appropriate System Definition (/Extra/smbios.plist) for your laptop. If your CPU ends in 'U', you should probably use MacBookAir5,2. If your CPU ends in 'M' use the ProBook Installer to create a custom MacBookPro9,1 or MacBookPro9,2. To create a MacBookAir5,2 smbios.plist, use Chameleon Wizard.

If you have Haswell, you should use a Haswell era smbios. iMac14,2 is available in Multibeast, but one of the Haswell laptop smbios might be more appropriate. Chameleon Wizard has support for MacBookAir6,2, but MacBookPro11,2 must be created manually (use Clover Configurator for clues).

That should give you basic power management (without TurboBoost), plus a bootloader and a starter /Extra folder. You can reboot and test booting directly from your HDD at this point.

Custom SSDT for CPU

Next step is to install a custom SSDT using the ProBook Installer. Download the latest ProBook Installer and select only the SSDT option. Click continue to install it. It is important to have your final smbios in place before generating a custom SSDT, so make sure you reboot with the smbios in /Extra before continuing to generate an SSDT.

Note: Much of the content in the ProBook Installer is specific to the ProBook. But not the SSDT generator. It can be used on any computer with a Sandy/Ivy/Haswell CPU, even desktops.

Note: For Yosemite, it is recommended you use the latest version of ssdtPRgen.sh script here:https://github.com/Piker-Alpha/ssdtPRGen.sh. The script contained in the ProBook Installer is an older version and may not work on Yosemite.

Now that you have a custom SSDT, you should make a few changes to /Extra/org.chameleon.Boot.plist:

- set GenerateCStates=No
- set GeneratePStates=No
- add DropSSDT=Yes

You can use Chameleon Wizard to edit these options if you're not familiar with XML plists.

Testing PM

After installing the custom SSDT, you should reboot and test it. You can test using DPCIManager (1.5) by using the PStates monitor. AppleIntelCPUPowerManagementInfo.kext will generally provide more accurate results. 

In addition, for Ivy Bridge or Haswell CPUs, you should run IORegistryExplorer and verify that X86PlatformPlugin is loading under the CPU0 node.

More information on Ivy Bridge PM is available here: ML: Native Ivy Bridge CPU and GPU Power Management

For Mavericks specific information, read here: Mavericks: Native CPU/IGPU Power Management

Checklist

Here is a quick Ivy/Sandy/Haswell Power Management checklist.

- patched AppleIntelCPUPowerManagement installed (except on Haswell)
- SSDT installed to /Extra/ssdt.aml for your CPU (easiest to use ProBook Installer)
- appropriate System Definition (smbios.plist) for your CPU
- DropSSDT=Yes, GeneratePStates=No, GenerateCStates=No
- no rollbacks of AppleACPIPlatform.kext
- no NullCPUPowerManagement.kext (usually implies patched AppleIntelCPUPowerManagement)
- Processor objects declared in Scope (_SB) or Scope (_PR) in DSDT (pretty rare not to have them in OEM DSDT)
- Verify that the generated SSDT injects into the same scope as Processor declarations in DSDT (usually _PR)

AppleACPIPlatform and EmbeddedControl

Note: For Sandy Bridge PM, it is possible to run a rollback of AppleACPIPlatform.kext but it is discouraged. Watch out for battery manager packages that include a rolled back AppleACPIPlatform.kext.

Note: Running stock AppleACPIPlatform.kext means any DSDT methods that manipulate EC (EmbeddedControl) registers larger than 8-bits will not work and will cause the method to fail. These methods must be patched. Access to such registers is common in DSDT battery methods. Some patches are provided at my laptop DSDT patch repository at: https://github.com/RehabMan/Laptop-DSDT-Patch

Note on older CPUs

For CPUs older than Sandy Bridge, use GeneratePStates=Y GenerateCStates=Y DropSSDT=Y. No need for custom SSDT (there are no tools to generate one).

Notes on Clover

With Clover there are slight differences, although the same concepts apply.

Here is a quick Ivy/Sandy/Haswell Power Management checklist as it relates to Clover:
- obviously, with Clover, you're using the Clover Installer to get a bootloader on your HDD. So there is no need to use Multibeast.
- patched AppleIntelCPUPowerManagement can be patched on the fly with config.plist/KernelAndKextPatches/AsusAICPUPM=true
- the kernel can be patched for XCPM (Haswell) with config.plist/KernelAndKextPatches/KernelPm=true
- the kernel can be patched for "Local APIC" panic with config.plist/KernelAndKextPatches/KernelLapic=true
- generated SSDT should be placed at /EFI/CLOVER/ACPI/patched/SSDT.aml
- appropriate System Definition (SMBIOS) for your CPU in config.plist/SMBIOS. Use the Clover Configurator to generate one
- to drop all OEM SSDTs, use config.plist/ACPI/SSDT/DropOem=true
- no rollbacks of AppleACPIPlatform.kext
- no NullCPUPowerManagement.kext (NullCPU is not even required during installation because AsusAICPUPM=true)
- Processor objects declared in Scope (_SB) or Scope (_PR) in DSDT (pretty rare not to have them in OEM DSDT)