Hervé

Then you've got a corrupt bootpack. Why don't you try Mavericks, Yosemite or El Capitan using more recents guides? https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-intel-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemite/

Try and boot in safe mode and without graphics enabler (-x GraphicsEnabler=No). If you reach the desktop, set OS X back to default OS drivers and remove the nVidia web driver. M4300 works fine with OS X default drivers.

Sorted. Installation had too many defects to mention, 1st one being an incorrect SSDT locking CPU to 800MHz... Installed the correct add-on kexts to /L/E, removed injected kexts from EFI/CLOVER/kexts, replaced AppleHDA with patched Yosemite version from Jake's Yos guides, activated DropSSDT in Clover, regenerated proper SSDT, etc. All is working, though I still can't explain those messages related to the prelinkedkernel that cannot be cached.

I guess you did not follow the guide to the letter, did you? You're either missing the correct permissions for the /L/E folder or not booting with the right boot options. Provided you've got the full pack in /Extra with DSDT + SMBIOS/boot/kernel plists + Extensions folder with all necessary kexts, you should be able to boot with the following flags and options: KernelBooter_kexts=Yes CsrActiveconfig=3 -f -v Once you've booted to EC, you can copy the kexts from /E/E to /L/E, repair permissions, rebuild cache and boot without KernelBooter_kexts option.

Hmm, I would not trust kext wizard for such a rebuild; I'd be scared it screws up the iMac. What I would recommend you do instead is the following: sudo chmod -Rf 755 /Volumes/<HDD partition name>/S*/L*/E* sudo chown -Rf 0:0 /Volumes/<HDD partition name>/S*/L*/E* sudo chmod -Rf 755 /Volumes/<HDD partition name>/L*/E* sudo chown -Rf 0:0 /Volumes/<HDD partition name>/L*/E* sudo touch -f /Volumes/<HDD partition name>/S*/L*/E* sudo touch -f /Volumes/<HDD partition name>/L*/E* /Volumes/<HDD partition name>/usr/sbin/kextcache -Boot -U /Volumes/<HDD partition name>/ -K /Volumes/<HDD partition name>/System/Library/Kernels/kernel

You will only be able to repair permissions and rebuild your cache once you've successfully booted your system (unless you have another partition on your disk that you can boot and perform those tasks from). Once you've deleted all unnecessary kexts from /S/L/E, you should be able to boot if you place all your add-on kexts and patched DSDT to the EFI/CLOVER folders of your EFI partition. Kexts placed in EFI/CLOVER/kexts/10.xx are injected at boot time, not cached.

-> PM

Sanitised. DSDT.dsl.zip DSDT.aml.zip

If you're missing the kext, that sure won't help. Here's the vanilla file from 10.11.3... AppleHDA.kext(v272.51.3).zip Your prelinked kernel appears totally locked so delete it with following command then redo those 2 touch and kextcache commands again. sudo rm -Rf /System/Library/PrelinkedKernels ` Jake, I understand better now... I'm not using Clover, i.e. no on-the-fly patches! Silly me!

Jake, these AppleHDA_IDT kexts have never worked for me. I've always needed the actual patched AppleHDA. You sure of those? Pirolito, I don't think the cache actually got rebuilt. Re-enter the last 2 commands. You should definitely have a warning for every kext added to /L/E; you did not get that. sudo touch -f /L*/E* sudo kextcache -Boot -U / or try: sudo touch -f /L*/E* sudo kextcache -system-prelinked-kernel The last one will most definetely recreate prelinked kernel and rebuild cache.

You'll find it in your AppStore purchases.

Did you disable hibernation? sudo pmset hibernatemode 0 sudo pmset hibernatefile /dev/null sudo rm -f /var/vm/sleepimage You also need to have native CPU power management working. That'll work natively on your C2D as long as you've enable P States and C States generation in your boot plist. Ideally, use a FakeSMC kext tuned-up to your SMBIOS profile too.

Ouh... npjohnson... That's like ancient stuff... And I see you've got really old stuff in there that you probably don't even need (AHCI_3rd_party, AHCI_injector, ElliotLegacyRTC (that goes back to Leopard 10.5 days!), ATAPortInjector, ApplePCIIDE, older ApplePS2Controller + VoodooPS2 controller (erm...), etc.). You could probably recover this installation but it's rather messy in my opinion and I'd recommend you start afresh. I would suggest you remove all those add-on kexts from /S/L/E, grab the appropriate E6420's pack from one of JakeLo's guides and follow the relevant guide. On a side note, you should always avoid copying add-on kexts to /S/L/E, it makes it hard to distinguish them thereafter. Always favour /E/E with myHack for SL, L, ML and Mav and /L/E for Yosemite and El Capitan.

With Enoch, unless you've created the /Extra/kernel.plist file, you need to boot with the option KernelBooter_kexts=Yes. In addition, there's no on-the-fly AICPUPM patch in Enoch so you either need to boot with NullCPUPM kext or the patched AICPUPM kext (available here). I assume that, by now, you know that SandyBridge (and IvyBridge) systems KP on vanilla AICPUPM (well-known BIOS MSR lock problem). Also note that kexts placed in /E/E will only be injected at boot time, not cached. It's totally similar to kexts placed in EFI/CLOVER/kexts/10.xx with Clover. If you want those kexts cached, set the KernelBooter_kexts option to No, copy your kexts from /E/E to /L/E, then repair permissions and rebuid your cache with Terminal commands: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U /

You're not typing things correctly; there's no space in /L*/E*. Just do a copy/paste if you have trouble reading or typing the commands. Once you enter the right commands as provided above, things will work better. You'll have one line of warning per kext added to the /L/E. NB: unless you kept your /Extra folder, you'd find yourself with a file called E* at HDD's root. Not exactly what you're after...

Indeed, the guides date from 3 years ago when EDP was quite different from what it's become today. ML was also still the active OS X release and had not reached final 10.8.5 version either. I would recommend you followed the following procedure that does not call on EDP at all (you can totally do without): install ML with myHack in the vanilla manner (i.e. without graphics support) using the Lion pack I've posted here but make sure to boot with manual option arch=x86_64 to overwrite the i386 option of the Chameleon boot plist (you undoubtedly know that vanilla ML can only run in 64bit kernel mode). It'll run slow/poorly without QE/CI but let's say that this will be temporary. update to ML 10.8.5 either through Apple menu or run the combo update. install all updates offered in AppStore (iTunes, Security updates, etc.). You'll most probably have to go through several steps and a few reboots. once you're running vanilla ML 10.8.5 with all OS X updates, run the MLPF app as per the guide to convert to 32bit ML. That should work. If I have time, I'll try to write new validated (i.e. tested) guides based on my full packs (i.e. no EDP involvement).

I'd say you somehow chose a relatively challenging way of upgrading from Mavericks to El Capitan. How did you configure Clover and what kexts have you used? Can you try and post your EFI/CLOVER folder of your EFI partition? Did you manage to rebuild cache or, alternatively, did you succeed in booting El Capitan without cache?

Please note that, starting with Yosemite, OS X kernels go to /System/Library/Kernels folder under the name of "kernel". As such, what you did by copying the kernel to HDD's root under the name of "mach_kernel" is an unnecessary step to me. Clover and recent versions of Chameleon/Enoch are fully capable to boot Yosemite and El Capitan with the kernel in vanilla name and at new default location. Your system KPs on EvoReboot so I'd remove that specific kext. What do you think? Personally, I've never needed it on my E6220 or the E6420 I briefly had between my hands. Since you're using Clover (I stick to Chameleon/Enoch), make sure to enable AsusAICPUPM option to cater for SandyBridge CPU power management and avoid related KP.

Once you've added kexts to /L/E, you must repair permissions and rebuild your cache: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / (or: sudo kextcache -system-prelinked-kernel) If you get error messages, re-type the last 2 commands.

? You either use VoodooHDA (and you have to disable AppleHDA) or you patch AppleHDA for your audio codec (and you'd probably have to patch your DSDT too). There is no "HDAEnabler" kext... Try an older VoodooHDA version such as v2.8.1 published in my D630 packs. You may also try to play with some settings in the VoodooHDA PrefPane.

No such issue on my D630 with v2.8.8, you may have something incorrectly configured in your Clover setup... Personally, I chose to stick to Enoch. CPU bus speed not set to anything above 200 000kHz in your Clover config for instance?

VoodooHDA only works provided you've also added AppleHDADisabler. The disabler kext usually comes with the VoodooHDA package. If you don't have it, install latest VoodooHDA v2.8.8. Google for it.

Ok, Intel i7-720QM is a quad-core Clarksfield CPU with DMI interface (or QPI) at 2.5GT/s. I guess that's what you're talking about when you mention FSB 2500MHz. DMI (QPI) was an evolution of the FSB and the latter no longer applies to Core generation CPUs. FSB applied to older CPU generation like CoreDuo, Core2Duo, Core2Quad, etc. The i7-720QM CPU has a nominal speed of 1.6GHz with Turbo boost to 1.73GHz (3 or 4 cores), 2.4GHz (2cores) or 2.8GHz (1 core). What I'm talking about by CPU bus speed is the actual base clock which, combined with CPU clock multiplier, provides the overall CPU speed/frequency. For instance, SandyBridge/IvyBridge/Haswell CPUs operate at frequency=multiplier x 100MHz (and all have a DMI of 5GT/s). This is what you typically see in HWMonitor app: In the case of the i7-720QM, LFM = 933MHz (the lowest frequency it runs at) and nominal multiplier = 12. As such, this CPU operates a 133MHz bus speed/base clock (1.6GHz / 12 = 133MHz). In HWMonitor, you'd see a multiplier of x7 at LFM speed, x12 at nominal speed, x13 at 3/4core Turbo boost (1.73GHz), x18 at 2cores Turbo boost (2.4GHz), x21 at 1core Turbo boost (2.8GHz). NB: I've read some people reporting inability to reach x21 multiplier with VT (Virtualisation Technology) enabled in BIOS... To have the expected "proper" CPU speeds reported, you'll need to configure Clover with a CPU bus speed of 133000 kHz. You should then see a CPU reported at 1.60GHz in "About this Mac" rather than 1.58GHz and same thing in HWMonitor.

Setting bus speed to 625000kHz sounds wrong to me. Arrandale (or 1st gen "i" core) CPUs typical use a 100MHz or 133MHz bus speed ('can't remember which). Which specific CPU model do you have?

In the case of Optimus, HDMI and DP may be wired to the nVidia GPU then.