Hervé

https://osxlatitude.com/index.php?/topic/8886-warning-10114-update/

https://osxlatitude.com/index.php?/topic/8886-warning-10114-update/

Latest released version of myHack (v3.3.1) does not support anything past Mavericks. As such, you have to use a "manual" method to build your USB installer. There are dozens of threads on this matter on this forum (and others). Look it up in the "Supported models with guides" section. You may then choose between Clover or Enoch bootloader, depending on your fancy. Personally, I find Clover much more difficult for beginners to grasp compare to Enoch, but it's much more powerful than a basic bootloader.

I guess we'll all experience this KP if installing the Thunderbolt or Recovery updates offered after updating to 10.11.4. So, avoid them.

Did you install offered Recovery + Thunderbolt updates? This is what causes the same KPs on all of my E6xx0 after updating to 10.11.4.

If it's anything like my E6220, E6320 or E6440, rebuilding cache won't change anything. I obtain this KP after installing the Recovery or Thunderbolt update after the 10.11.4 update. So, these may be best avoided. The only way I can reboot (sort of safely) is by limiting CPU to single core (using Enoch option cpus=1). Have not sussed out the problem yet, so only fix at my disposal for the time being is... to re-install!

DW375 works OOB afaik but you can patch the Broadcom Controller kext to be able to enable/disable BT. The SD card reader normally works with patched VoodooSDHC kext... PS: your COMMAND-key functionality has been in existence for some time. And it just does not apply only to wifi, try it on other Finder's bar icon if you wish.

It sure does not look good, does it?

KP on "CPU x" with "Double fault..." error message -> try booting with single CPU activated.

USB3.0 ports work Ok and natively on same generation Haswell-Based QM87/Series 8-chipset E6440. Just make sure to have the proper DSDT patch in place ("Darwin" OS injection) as documented in my E6440 guide.

You may also unplug your USB installer from one port to replug in another.

Or you can use the Hackintosh Vietnam Tool to apply IDT 92HD90 patch to the current/active kext.

@griftopia: when you get the "still waiting for root device..." message, try to simply unplug then replug your USB key. Sometimes, it gets the boot process to continue. Please note that, as hinted by Bronxteck, there are 3 x USB ports on the E6500: 2 x USB2.0 at the right + 1 combo e-SATA/USB2.0 at the left. Do think of checking your system's specs on the manufacturer's web site...

'played a little further to get the DP port of my E-Port Replicator K07A002 to work. I don't have a DP-capable display so I used a DP-to-HDMI adapter to connect to my HD TV. Output display + HDMI audio through DP port was then obtained when setting port number to 6 in any of the display output lines. For instance: 02 05 00 00 00 08 00 00 06 00 00 00 or 04 06 00 00 00 04 00 00 06 00 00 00 We can therefore deduct that DP output is available through port #6. With that revised config I retain direct HDMI output through the E6220 built-in HDMI port but no HDMI audio, except through DP port (!). In terms of FB and connector type details, IOReg shows: FB@2 -> DP, port #6, connector-type 0004 0000 'seems to go to the detriment of VGA output though...

Please try and understand what you're doing. Why would you patch the VoodooSDHC kext with Broadcom card reader id 14e4:16b when that device is natively supported by OS X? You only patch the VoodooSDHC kext with your own card reader id (i.e. 10ec:5227 ), nothing else. 1) You patch the VoodooSDHC with your own hardware id so that you try to get the card reader working through that kext /driver or (and only OR, not AND) 2) you patch your DSDT to declare your own card reader compatible with OS X natively supported/default model; the idea is that OS X then loads its native SDXC kext/driver to handle your own hardware. Bottom line is that you must not mix the VoodooSHDC kext + DSDT patch for native SD card reader recognition. You use one OR the other. Bear in mind that there's no guarantee at all that this will work. SD card readers are like webcams: some work, some just don't.

You're trying to add a SDXC device when your DSDT already has a PXSX device under RP08 (assuming that's where you've located your SD card reader). That's wrong. Then, you're missing the DTGP method, so you need to add that too. Anyway, can't really do anything without your IOReg to verify things!

HD4000 is supported on the E6x30 with Capri FB #3 (i.e. layout id 01660003). So, either you boot with options such as IntelCapriFB=3 or InjectIntel-ig=03006601 (or ig-platform-id=03006601) or you inject the following code into your DSDT if it's missing (it should not if you use the bootpack from this site). The code goes into the graphics device located at address 0x00020000 (GFX0 or -ideally- IGPU). Method (_DSM, 4, NotSerialized) { 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" } }) } Audio will work once you patch AppleHDA and potentially add the IDT dummy AppleHDA kext. Trackpad will work with the correct PS2 controller (VoodooPS2Controller in the present case). All of those are readily available in the various bootpacks and/or guides for the E6x30 series. Please look these up.

I personally tried it, to no avail...

The patched SNB framebuffers in my posts are for Mavericks 10.9.5 or Yosemite 10.10.5. I would not expect them to work in ElCapitan. All you need to do is hex edit the binary file of your current 10.11 installation with a tool such as HexEdit or similar (0xED tends to be problematic under El Capitan so it's best avoided) according to the published info. Alternatively you can look at perl Terminal commands to make your binary substitutions. Plenty of samples all over the Net. Start by reading this guide. Then go back to the threads I refered to in post #2.

1) you identify your hardware device in IOReg with a tool such as IORegistryExplorer. 2) then you look up that device in your DSDT 3) you add the ACPI code under that device in your DSDT. All this is already mentioned in the post...

No, please read up the post I linked to.

You could try a DSDT patch in the line of what was done for Dell Latitude E7x40/E6x40 and others: https://osxlatitude.com/index.php?/topic/7387-dell-latitude-e6440-with-i5-4300m-hd4600-and-1600x900-lcd-mavericksyosemite/page-3&do=findComment&comment=49190 An alternative is the SDHC kext but you'd probably need to patch it with your own card reader id as a pre-requisite.

And if you simply drag the dummy HDA file to /S/L/E, you won't get audio. You need to repair permissions afterwards (and, ideally, rebuild the cache too). Permissions: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* ` Cache: sudo touch -f /S*/L*/E* sudo kextcache -Boot -U /

I've got the same issue on my E6440 and E6230 since installing other updates after 10.11.4: panic (cpu n caller 0x......): "Double fault at 0x...... I can only succesfully boot with Enoch option cpus=1. Try the equivalent with Clover if that exists. I updated 10.11.4 through AppStore, not combo update. I'll re-install 10.11.2/10.11.3 and retry with the combo in case it makes a difference. There is definitely something fishy with 10.11.4 update.

https://osxlatitude.com/index.php?/topic/8278-e6320-with-hd3000-booting-yosemite-with-dell-docking-station/ https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemite/&do=findComment&comment=57882 Apply same principles to your EC build and patch the SNB frame buffer kext.