Hervé

So you're talking about CPU utilisation, not CPU speed, right? What does your Activity Monitor show? did you install something that could always run in the background and grab CPU ? Which OS X version are you running by the way?

What is it you're after exactly? If you don't want your CPU to run without Turbo modes (i.e. slower) when laptop is on battery, remove the Turbo disabler kext, then rebuild your cache. For the rest, I assume that you've generated your own CPU-specific SSDT using the well-known SSDT generator from Pike R Alpha and that your system runs with proper CPU power management/speedstep.

Make sure you disable SIP and use this PS2 controller or this one.

Finally got round to implement the HPET fix in DSDT to avoid loss of USB functionality rather than systematically remove the HPET kext. It's a simple matter of removing the IRQs as detailed by Slice (and others) for instance: Before: Device (HPET) { [...] Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) [...] After: Device (HPET) { [...] Name (BUF0, ResourceTemplate () { IRQNoFlags () // Excludes IRQs 0, 8 and 11 to prevent loss of USB ports {0,8,11} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) [...]

Are you running with the Turbo disabler kext?

Seems you're booting the recovery partition... Maybe you need to rebuild your USB installer.

There never was any fix to the black screen issue, if waking the screen from screen sleep. The only workaround is to put the laptop to sleep and wake it. As such, it's best to configure the same timing for Display Sleep and Computer Sleep in the Energy Savings PrefPane. The system password was a requirement for GMA950 systems and does not apply to nVidia models. The D620 NV does not normally have an issue of KP on wake. Mine certainly does not.

You can look at my research on the matter in the R&D->Graphics section. It was done for my Haswell laptop but the principles remain the same. You need to identify your DP port through an IOReg browser (IORegistryExplorer, IOJones), then experiment with binary modifications of your relevant layout-id section in the BDW framebuffer.

For the HDMI audio patch, all that's required is to modify the HDMI output connector-type from its default value of 00 04 00 00 to 00 08 00 00. This patch is applicable to all systems whatever the frameBuffer (SNB, Capri, Azul, BDW, etc.) and for all versions of OS X. So, you need to identify the HDMI port line in your particular layout-id of the Broadwell framebuffer (kext BDW FB) and then apply the binary patch; this can be done "on-the-fly" through Clover or through direct binmod of the FB binary file itself.

HDMI audio is handled through AppleHDA (patched for your own codec) + Intel framebuffer (patched BDW FB in your case).

By 2016, everyone who's done a minimum research should know that no Intel wireless card is supported under OS X. It's even mentioned in the FAQ section: https://osxlatitude.com/index.php?/topic/8696-is-my-wireless-card-compatible-with-os-x/ Please use the forum Search facility before posting.

A change to the SMBIOS profile may help, like a little jiggle of the production week n° or year to generate a different serial n°. Assuming the SMBIOS chosen model is right...

The only 10.11.3 you could download would be the Combo update. And that would only install on an earlier 10.11-10.11.2 build. Apple only provides the latest version for installation package download. Oh and, no, 10.11.3 would not work better than 10.11.4+ on that system. Maybe you should make a new installation...

Does it boot if you limit your CPU to 1 core (eg: option cpus=1 in Chameleon/Enoch)?

Means the cache was not rebuilt. Re-type the last 2 commands or use the following alternative command for kextcache: sudo kextcache system-prelinked-kernel

Updated with 10.11.6 files.

Is your Ethernet interface set to en0? That's mandatory.

Looking ok. But if you keep getting "wrong password", then you're not entering the right one...

FaceTime, like AppStore, should only require Ethernet to be up & running as en0. The other stuff is for iMessage.

Yes, you need to copy the EFI folder to the EFI partition. You can mount it with Clover Configurator.

Reset your BIOS to factory settings, then set AHCI on and disable Optimus.

Please read the guide before asking questions answered there...

Correct.

Hmm, I've made additional tests and, since my dGPU appears turned off at boot time, I tried to turn it on through SSDT or DSDT edits. I've not managed to reach success yet. However, this reminded me that, many moons ago, I had noticed that HWMonitor never displayed any info about GPU at startup, only after wake. Basically, I would get this: At startup and until sleep After wake Now, if you look at the DSDT code for the _WAK method, you'll notice the following section: If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON)) { \_SB.PCI0.PEG0.PEGP.EPON () } If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) { \_SB.PCI0.RP05.PEGP.EPON () } } ` To me this code is partially erroneous in the sense that there is no PEGP device under RP05 in any ACPI table, however the discrete GPU is definitely handled by PEGP under PEG0. Check what you get in HWMonitor at startup. If no GPU info appears, I believe your dGPU is off. If it appears, we'll have to find the right code to turn it off. If, like me, your dGPU appears turned on only after wake, apply the following DSDT patch: edit the SSDT table where method EPON is defined and create a new EPOF method (it did not exist in my SSDT-xx table). EPON method only sets ONOF parameter to 1 (true) so you can simply copy/paste the EPON code in a new EPOF method where you set ONOF parameter to 0 (false). in the above DSDT _WAK code, you can then replace the call to EPON by a call to EPOF instead. In the relevant SSDT table, you may notice that the ONOF parameter is used in SGON and SGOF methods that turn the dGPU on or off. although it would appear like the obvious thing to do, removing the above _WAK code is simply ineffective. In a nutshell: in your relevant SSDT-xx table, add this after EPON method: Method (EPOF, 0, Serialized) { Store (Zero, ONOF) Return (Zero) } in your DSDT, change the _WAK code to: If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPOF)) // Replace EPON by EPOF { \_SB.PCI0.PEG0.PEGP.EPOF () // Call to EPOF to turn off dGPU } // Comment out or remove those useless 4 lines below // ------------------------------------------------- // If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) // { // \_SB.PCI0.RP05.PEGP.EPON () // } } // <----- Don't remove or comment out that closing bracket! ` I think that should sort you out if dGPU is indeed turned off at startup and only activated after wake. Meantime, I'll keep trying to find the right code to really turn on or off the dGPU at system startup.

Where is your ApplePS2Controller kext? If in /L/E, make sure you repaired the permissions of that folder and rebuilt the cache. I've no issue with the kexts of the pack I published and my D630 runs 10.11.6 without any mods to kexts. If you get an error message at the end of cache rebuild process, just repeat the last 2 commands (touch + kextcache).