Hervé

On those models, Fn-F8 has no adverse effect other than screwing output display. You don't necessarily need to restart the system, one can usually recover by putting the system to sleep, then wake it. I guess you probably did not think of that. If you screen looks different that it did before (I assume you meant the Finder's bar icons), I guess you've probably been messing with elements of display rendering in the General PrefPane through more accidental key strokes... You just need to get to learn those Yosemite/El Capitan's functional details a little better. You should easily find the fix...

Those issues have nothing to do with Enoch. Enoch is a boot loader and that's it. The AppleHDA patch is widely available for the IDT 92HD93 codec of the E6430. It's just a matter of searching for it. For USB 3.0, I'd say there's a very good chance that the built-in Intel controller can be natively supported. USBx.0 issues are a "simple" matter of DSDT tuning + USB injector creation for your chosen SMBIOS profile. Again, this is widely documented and can be found through forum searches. Here for instance. Anyway, this is all off-topic, this thread was about HD4000 artefacts and can be closed.

I've found that, in OS X, it's better to distinguish both networks than use the same SSID on both 2.4GHz and 5GHz. I personally had an issue with 2 x 2.4 & 5GHz networks that shared a common SSID... until I used 2 x separate SSIDs. All my troubles then went away and I could connect safely and in a stable manner to one or the other. Symptoms were different from yours though as I was experiencing connection dropouts; doesn't seem to be the case for you, so I'd say the patches Bronxteck linked to are probably required.

After further testing, HD3000 of E6220 is to be able to support the following combinaisons of 2 x concurrent displays: LCD + VGA, LCD + DVI, LCD + HDMI, VGA + HDMI, VGA + DVI, DVI + DVI, etc. Please note that Intel SandyBridge graphics cannot support 3 independant displays. I've updated my E6220 SNB patch to reflect port number and connector types as reported in IOReg: 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 06 02 00 00 00 04 00 00 08 00 00 00 // patched: VGA, display port #8, (built-in + docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // vanilla: DVI, display port #7, (docking-station port) NB: VGA output is also fully functional with connector type 0001 0000, 0010 0000 or 1000 0000 not just with DVI/DP connector type 0004 0000.

I've spent some additional time on the E6220 and the E-Port replicator K07A002 trying to work out multiple external displays. At 1st, things looked hopeful and promising, but I never reached the targeted goal. Even though OS X did report 3 x displays (LCD + VGA + DVI), only one external display worked, never both... No problem getting 2 x external displays with LID closed though. That works perfectly. Then I found that SandyBridge graphics do not support 3 independant displays, only 2, so that figured! I slightly updated my SNB FB kext's patch to reflect port numbers and connector types as reported in IOReg: FB@0 -> LVDS, port #0, connector-type 0200 0000 FB@1 -> HDMI, port #5, connector-type 0008 0000 FB@2 -> VGA, port #8, connector-type 0004 0000 or 0001 0000 or 0010 0000 or 1000 0000 FB@3 -> DVI, port #7, connector-type 0004 0000 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 06 02 00 00 00 04 00 00 08 00 00 00 // patched: VGA, display port #8 (built-in + docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // patched: DVI, display port #7 (docking-station port) 10.10.5_Patched_AppleIntelSNBGraphicsFB.kext.zip

Pirolito, really, the boot pack is saved on your desktop in a folder called "ElCapitan_E6430_Pack". What more can I say?... Looking at the recent gusts of new threads and posts re: EC installation of those E6x20/E6x30 with Clover, I'd say stick to (Chameleon) Enoch. Clover really seems difficult to newbies (no offence meant). You can follow the same process I've detailed meticulously for EC on the D630 nVidia. Obviously the pack will change, but you already have it.

These options are already contained in the files provided in the pack (CsrActiveConfig is in the boot plist and KernelBooter_kexts is in kernel plist) so I guess you did not follow some of the steps of the guide… The guide makes a very specific mention to these parameters and their use. You can do all the OS updates you want with your eyes closed. As long as you've placed all add-ons in /L/E, your D630 will keep on working.

Time to make a fresh installation...

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?