Hervé

A newer version v1.3.6 of that kext has been available for a few months...

As listed at the very bottom of your forum page... http://www.osxlatitude.com/tuning-performance-with-fakesmc-smbios-plist/

What kind of SSD do you have? I experienced this behaviour with an Intel SSD model once Trim was enabled. Ok without.

Well, I initially also used the MBA6,2 for my Haswell-based E6440, then changed that to MBP11,1 as that gave me one extra intermediate CPU multiplier. Try and tune your FakeSMC kext too, that may modify iGPU behaviour. You never know and no harm to try...

OS X is generally more graphics demanding than Win7, so it's perfectly normal to me that battery life is shorter under OS X than it is with Windows. Depending on SMBIOS profile and FakeSMC tuning, you may optimise CPU speed stepping and possibly gain a little battery life. I take it you're using a CPU-specific SSDT to handle good CPU power management. You may also want to turn off accessories such as Bluetooth if you're not using them.

If your (mini) DP port is not working, you have no other solution than find out the correct FB adjustments to get it working. Once you've found out the correct settings, it'll be "rock solid" across the board. The HD4000 thread provides all the necessary info to get you going. You will not get a generic/standard solution that fits all machines if that's what you're after. You'll have to experiment; that's Hackintoshing I'm afraid... To give you an idea, you may find inspiration in this thread (look at posts #5 to #8). It's for SB HD3000 outputs, but the principles remain exactly the same for HD4000 outputs.

You may check the dedicated thread on HDMI/VGA output on HD4000 in the R&D section. It details the various binary patches to consider.

Are you sure you've got full graphics acceleration? One sure way to know, if you have a CD/DVD drive is to launch DVDPlayer app then check the Supported Features in Help menu. All should be supported. For AppStore, make sure you've installed the Ethernet kext and that your LAN card is detected as en0; if en1, remove all interfaces from your Network PrefPane, then all plist files from /Library/Preferences/SystemConfiguration and reboot.

When you get this error 77, redo the last commands (touch + kextcache). Failing that, opt for: sudo kextcache system-prelinked-kernel

Hmm, it's as if your graphics are not initialising. Check that you have the DSDT in its expected place and that it contains the appropriate SNB layout-id. Make sure to boot with: Enoch flags & parameters KernelBooter_kexts=Yes -f -v Extra folder copied to your USB installer Patched AICPUPM kext in place (/S/L/E) or NullCPUPM kext in /E/E

Boot in verbose mode (-v flag) to try and grab where the boot process hangs. But if you have same hardware + same BIOS version + same BIOS settings, I'm failing to think of anything specific.

Afaik, you only patch the Capri FB in order to gain specific video output(s) such as HDMI and/or VGA for instance. I think this was mentionned in previous posts. HD4000, like HD3000 before it, has no built-in dedicated VRAM; as such, for memory, these iGPU use computer's RAM.

Check that your HDD mode is set to AHCI in the BIOS settings. OS X does not usually support modes such as RAID. One other thing you may try when you obtain the "waiting for root device" is unplug then replug your USB installer key.

You need the patched AppleHDA kext in /S/L/E + the codec specific AppleHDAxxxx kext in /L/E. If you have Clover, you can simply add the on-the-fly AppleHDA patch to your config plist.

I could not say whether your friend's statement re: VGA control is true or not, but VGA output off IvyBridge iGPU is not usually supported OOB under OS X and requires FrameBuffer patching. Since you run on your integratedHD4000, I would expect you need the VGA patch applied to your Capri FrameBuffer. You'll find details of the patch here. Identify your active HD4000 layout-id (0x0166xxxx), then experiment with the described VGA patching possibilities until you hopefully find the value that works. Keep a backup of the vanilla Capri FB of course!

KP=Kernel Panic -> means system crash.

Check that you have: 1) the Extra folder at USB installer root and that it contains the kernel + org.Chameleom.Boot + smbios plists & the correct kexts in Extensions subfolder (FakeSMC, VoodooPS2Controller and NullCPUPM being mandatory to begin with) 2) that the kernel.plist file does contain the parameter KernelBooter_kexts set to Yes

You may look here. Very complete and up to date general guide afaik.

A few things to do on your USB installer: remove the SSDT provided in the bootpack from /Extra (it's for a i5-3340M and unsuitable for your i5-3320M) if it's missing, add the attached NullCPUPM kext to /Extra/Extensions folder reboot NullCPUPowerManagement.kext.zip

BIOS version and CPU model? Post a (1024x768) picture of General->System Information BIOS page.

You've got your answers above. Please read them.

Again, please read and follow the guide! The guide clearly states it applies to the E6230 fitted with i5-3340M CPU (CPU-specific SSDT in the bootpack). For other CPUs: Did you read that too?

As stated in the guide: It'd please me if you could read the guide with a little more attention... I made every effort to post an orderly step-by-step procedure and every step is required.

As stated in my previous above, USBInjector is of no help for your issue. It's your DSDT...

You might have been, yes... I'd restore them if I were you. Looking at the DSDT (dated May 2016) you posted on May 24th, one will notice that none of your EHCx or HDEF devices have the usually required _DSM method that defines power settings and is required for sleep. I would suggest you add this to the DSDT devices. You'll find details of the code all over the forum. Here for instance. If, after that, you still have issues like instant wake, you may adjust the _PWR methods for those given devices. All according to info posted by Rehabman on his blog. Re: USB injector, it's used to get USB ports to work (be recognised), not really for sleep or wake. The SMBIOS you use must match the model configured in the USB injector and the ports specified in the injector must match those defined in the DSDT... The injector kext posted above would gain by being substantially optimised (read: remove all unnecesary entries). Look here for details re: creation of an adequate and optimised USB injector.