Hervé

USB, Ethernet and video outputs all work Ok. Audio ports don't appear recognized.

The E6420 BIOS settings & options should look very much liked those of the E6220. https://osxlatitude.com/index.php?/topic/8281-e6220-bios-settings/ You can also refer to my Chameleon/Enoch-based E6220 guide as an alternative to Jake's Clover-based guide. The process remains identical between all E6x20 models and most files are useable on all models. You only need to adapt DSDT if using a high res LCD.

Ha, that's different from the description you gave before. I understood your laptop went to sleep Ok but just woke to dark screen. Assuming you configured hibernation mode to 0, what you'll probably need here is a DSDT patch... None of your EHCx/XHC USB devices or HDEF audio device appear to have the (usually) required _DSM method: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x0B) { "AAPL,current-available", 0x0834, "AAPL,current-extra", 0x0898, "AAPL,current-extra-in-sleep", 0x0640, "AAPL,max-port-current-in-sleep", 0x0834, "AAPL,device-internal", 0x02, Buffer (One) { 0x00 } }) } Try either of the attached patched DSDT tables. The 1st one includes the above patch in EHCx, XHC and HDEF devices; the 2nd one has same + _PWR methods removed. DSDT01.aml.zip DSDT02.aml.zip

I don't believe these log messages are an issue. If you end up with a booted OS X with full QE/CI, then consider things work.

Well, if layout-id 01660009 is the only one that seems to give your graphics acceleration, I guess that's what you should stick with. Regarding black screen on wake, you could try and use boot option darkwake=0 to see if it makes any difference.

What resolution is your built-in LCD screen?

You're not the 1st one to do this but do not confuse your hardware id + revision id with graphics FrameBuffer layout id. It's not the same at all. Just because you have an HD4000 GPU with hardware id 0166 and revision 9 does not mean you use HD4000/Capri layout-id 0x01660009. Far from it, but it does not mean that it should not either... Many (most?) IvyBridge Hackintosh laptops with HD4000 graphics will actually use layout-id 0x01660003. Look at my E6230 for instance (i5-3340M CPU)... SysProfiler shows device id 0166 with hardware revision 9, but we use layout-id 0x0166003 in the DSDT: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x04) { "AAPL,ig-platform-id", Buffer (0x04) { 0x03, 0x00, 0x66, 0x01 }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }) }

Did you install any 10.11 update such as 10.11.4 or 10.11.5? Boot in verbose mode and post what you obtain.

I've no personal experience with the E6500 nVidia but I guess that, yes, HDMI and/or DP should work too. You'll find out soon enough.

Your laptop is fitted with a high-end Penryn mobile C2D CPU + nVidia NVS 160M GPU. It should run decently enough with all latest OS X version from Mavericks to El Capitan. My D630 nVidia is of slightly lower specs and runs perfectly under Mav/Yos/EC. It's no power beast by today's standards of course but perfectly usable daily for general desktop activity, browsing, music or videos. You'll have to replace your DW1397 wireless card by another model as it won't be supported in recent OS X versions. https://osxlatitude.com/index.php?/topic/2120-inventory-of-supported-and-unsupported-wireless-cards/

No, why would you do that? You'd only modify the FB kext to gain VGA/DVI/HDMI output if not natively supported. You cannot modify the FB to make your internal LCD recognised as such. You have to get graphics supported under a mobile HD4x00 layout. Try them all and see how it goes. I believe you'll never get anywhere with a desktop layout. Your Clover config.plist also showed a custom EDID, did you try without it?

The Extra folder you posted some time ago shows an incorrect SMBIOS: MacBookPro5,1. That's a Core2Duo model, not a SandyBridge-based model with integrated HD3000. Make sure you use a suitable profile such as MacBookPro8,1/8,2/8,3. Use Chameleon Wizard to select such a profile and save the SMBIOS plist in your /Extra folder. With Clover, you'll have to use the Clover configuration tool. If you're still not getting any joy, then I would again say that this basic version of SandyBridge Intel HD is not supported and you will never get graphics acceleration (as with HD2000). Overall, this Packard Bell laptop is quite a poor/limited system anyway. It was a cheap low-spec system when commercialised... In that case, my advise is to forget running OS X on it. El Capitan, Yosemite or otherwise, it makes no difference; if this SB GPU is unsupported, that is across the board. You can't even change the CPU for a Core i model due to chipset, so you're kind of stuck with what you got. NB: Capri framebuffer is for Ivy Bridge systems, so not applicable here. Don't confuse things.

When the built-in LCD is not detected as such, the fix usually consists of patching the PNLF device in DSDT and/or adding boot display info to the IGPU device @0x00020000. The patched DSDT I upload previously included this. But I think you're not using the correct config for your graphics/display. You have a laptop with HD4200 graphics and, as such, you should be using a mobile layout such as 0x0a260006, not a desktop one like you currently do with 0x0d220003. Desktops don't have built-in LCD per se... To me, that's where your issue is.

Indeed, this has been extensively discussed on the forum before. You can use the forum Search facility or browse the R&D/Hardware/Wifi section.

Just to clarify things regarding framebuffers: HD3000 graphics of Sandy Bridge CPUs i3/i5/i7 2xxx CPUs is handled by SNB frame buffer kext HD4000 graphics of Ivy Bridge CPUs i3/i5/i7 3xxx CPUs is handled by Capri frame buffer kext HD4x00/5000 + Iris 5x00 graphics of Haswell CPUs i3/i5/i7 4xxx CPUs is handled by Azul frame buffer kext You have an Ivy Bridge i5-3317U CPU with integrated HD4000 graphics so the Capri FB is the only one of concern on your laptop.

If you have a myHack-based installation, kexts are meant to be placed in /E/E then you run myFix (quick).

More likely to be an issue with DSDT battery device. Rehabman's repo has a number of patches for that.

It's nv_disable=1 (all in lower case). You must respect the syntax as provided by Jake.

I've mentioned this before here but cannot track the post... You may be in the presence of a 2.4Ghz and 5GHz wireless networks using the same SSID and/or encryption key. I've been in that situation before and encountered disconnection issues such as yours. I've detailed the deployed fix here. It's an easy one... You may also take Dell's info on the matter into account.

What kind of patch do you have in mind? I'd say this Sandy Bridge Intel HD graphics is also unsupported, after all, it's based on HD2000.

I would not know what to do with that dump, sorry... Here's a revised DSDT that injects mobile HD 3000 id 0x0126. It needs to be used with restored vanilla graphics kexts. DSDT.zip

Well, you're going to have to explain your installation build and how you install kexts.

Try and repair kexts permissions then rebuild your cache.

AppleIntelBDWFramebuffer.kext is for 5th gen Broadwell IGPUs. I just cannot see the relevance of that kext in your specific SandyBridge context. You should revert to plain vanilla graphics kexts throughout. Patching of SNB kexts is not usually required to reach OS X desktop. Usually, it's only necessary to obtain specific display output such as DP, DVI or HDMI. Try to fake HD3000 by injecting mobile HD3000's id 0x0126 in your DSDT as opposed to mobile (SNB) Intel HD's 0x0106. The patch will then look exactly as posted above.

Hmm, did you ever adjust your PS2 keyboard kext as detailed here?