Hervé

Yes, you're right about that DSDT GPU-related error (device-type has to be set to "NVDA,Parent", model is just cosmetic). It's been mentioned before and fixes posted in threads but I don't think the bootpacks were ever modified. In addition, if hibernation must indeed be disabled, any hibernation file must also be removed from /var/vm. One sure way to avoid creation of such file is to set the hibernation file to null device: sudo rm -f /var/vm/hibernatefile sudo pmset hibernatefile /dev/null

I've just realised that the tuned FakeSMC I gave you contained AGPM tuning for the NVS 135M GPU. Can you look at the device id of the NVS 140M as listed in SysProfiler->Graphics/Displays? If, as I suspect, it's not the same as the NVS 135M of the D630, the AGPM tuning section of the kext needs to be adjusted accordingly... This would explain why you're losing GPU throttling after wake. nVidia Quadro NVS 135M = ven id 0x042b nVidia Quadro NVS 140M = ven id 0x0429 ?

Patched_AirPortBrcm4360_MBP9,2.kext.zip (of 10.11.3 origin) It does not matter which PCIe slot the card is into, they're run the same way.

You can install Enoch (r2795) on the 1st partition of your bootable HDD and safely boot all 3 versions of OS X. For EC 10.11, you'll need to create a kernel.plist file in /Extra in which you can specify some kernel related boot parameters. In your usual Chameleon boot plist, you'll have to add the new CsrActiveConfig parameter and set it to 3 (or whatever other value you may fancy to disable SIP). Add-on kexts should be placed in /Library/Extensions, permissions repaired and cache rebuild using the usual Terminal commands: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / If any error messages are displayed about cache or prelinked kernel rebuild failing, repeat the last 2 commands If you do not want to cache add-on kexts (quicker boot), but simply inject them at boot time (slower boot), keep them in /Extra/Extensions, then add kernel boot option KernelBooter_kexts=Yes in /Extra/kernel.plist If you ever need to boot with -f -v flags, you may find you need to also add KernelBooter_kexts=Yes.

Sigh... Oh look: a jelly fish! http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=Y1VCD

Typical DualLink parameter issue... HiRes DSDT will have IGPU DualLink parameter set to 1; you need this set to 0 on a LoRes machine. Adjust the DSDT (you may use the related boot option meantime). In your DSDT, lookup for the IGPU device (or whatever it's called) at address 00020000: Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x0A) { "AAPL00,DualLink", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 /* adjust according to screen res */ }, "device-id", Buffer (0x04) { 0x26, 0x01, 0x00, 0x00 /* Intel HD 3000 */ }, "model", Buffer (0x18) { "Intel HD Graphics 3000" }, "AAPL,snb-platform-id", Buffer (0x04) { 0x00, 0x00, 0x01, 0x00 /* Sandy Bridge framebuffer */ }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }) }

Sandy and Ivy Bridge systems require the AICPUPM patch (AsusPM or something like that, can't remember its exact name in Clover).

Just keep a copy of all your specific files in a "pack" folder (DSDT, SSDT, kexts, Chameleon boot plist/SMBIOS plist, Clover config plist, Enoch kernel plist, etc.). Thereafter, the process to create a USB installer and to install OS X is always the same for Yosemite and or El Capitan. For earlier versions, you could use myHack with a computer-specific bootpack (or a generic one).

Clearly, you can't re-use it "as is"... the DSDT is specific to the D630 model and so will be some of the kexts (like LAN for instance). Only reuse the common ones like FakeSMC and PS2 controllers.

It's based on Atheros AR5B195 as indicated on its label... --> https://osxlatitude.com/index.php?/topic/2120-inventory-of-unsupported-and-supported-wireless-cards/ --> https://osxlatitude.com/index.php?/topic/2925-bluetooth-firmware-uploader/

Enoch r2795 highly recommended. You should update your bootloader. Did you configure a kernel.plist file? Mind you, I can't remember if that was available before r2760 ? With r2760 and above, kexts placed in /E/E won't be injected (loaded) unless you set KernelBooter_kexts boot option to Yes. If you want to cache them, move or copy them to /L/E (or /S/L/E), repair permissions, rebuild cache and boot with KernelBooter_kexts set to No.

StarTech PEXSAT34 works OOB under OS X version from SL 10.6 to Yos 10.10. Not tested beyond Yosemite (deskop used for testing is far too old) but no reason why it would not. It's a PCIe 2.0 in x4 format offering 4 x SATA-III ports under Marvell 88SE9123 controller. Port #1 can be shared with eSATA port at the rear. NB: in my Precison 670 where the card was fitted to a PCIe x4 v1.0 slot, a single port only operates @250MB/s, i.e. single PCIe lane, which contradicts what StarTech support stated to me: that a single SATA port would run through all 4 lanes. In fact, it seems to me that the card operates at 1 x PCIe lane per SATA port and that there is no concatenation of lanes at all; at least on my old dinosaur. I also obtained slightly poorer benchmark results than with above PCIe x1 model.

It'll work OOB with a little DSDT patch as explained here. You just need to identify the DSDT device your card reader is attached to in IOReg.

That'll depend on the model... Which is it? What are its PCI ids? If a PCI device, you can look it up with DCPIManager app, if it's a USB device, you should see in in SysProfiler. Or extract an IOReg with IORegistryExplorer app and post it.

Are you following this guide? Just in case, default your BIOS settings then configure them according to the recommended config as detailed in the dedicated pinned thread.

And please, pretty please, stop quoting the messages to which you directly reply!

N73 same model as N53 ?

Hmm, try the files from the D630 pack. We can always switch DSDT afterwards and adjust as required.

Sounds like you may not have CPU power management working properly and that your DSDT requires patching

Afaik, nothing special required for those particular models, no. vPro is some Intel marketing label just like Centrino was. Consider it a set of specific security-oriented features. Apart from that, vPro CPUs remain the same as non-vPro. https://en.wikipedia.org/wiki/Intel_vPro http://www.intel.com/content/www/us/en/architecture-and-technology/vpro/vpro-technology-general.html?_ga=1.79303059.645950130.1454350102

Which version of OS X did you install? Try a more recent ACPIBatteryManager kext from Rehabman. You can Google for it.

Then you know what's left to try...

There's no sign of a Bluetooth device on your USB bus... Are you sure you have the AzureWave model with Bluetooth? There is a 943225HM (no BT) and a 943225HMB (with BT). If you're certain to have the HMB model and BT works in Windows, I'd strongly recommend you tape Pin20 as suggested by Bronxtech. Windows might be disabling BT on shutdown (taping Pin20 would keep the card fully activated). You could also try those 2 kexts in /S/L/E. They're Rehabman's work. They're also for ElCapitan, not for earlier versions but Rehabman's repo stipulates that the AzureWave BCM943225 does not normally require special FW for Bluetooth to be operational under OS X; 'should work OOB... BrcmFirmwareRepo.kext.zip BrcmPatchRAM2.kext.zip

The left side USB port is not functional OOB under El Capitan. It's the well-known USB ports problem... I have therefore revised the patched DSDT for El Capitan, with USB2.0 devices renamed from EHCx to EH0x in order to use the attached USB2.0 injector kext. The original DSDT code shows 2 x USB2.0 controllers: EHC1 @1D: 8 x ports, numbered PR11 to PR18 under hub PR01 EHC2 @1A: 6 x ports, numbered PR11 to PR16 under hub PR01 and the physical USB ports appear arranged in the following manner (as visible in IOReg when a device is plugged in the ports): EHC1 controller, port #1 (PR11) @1D11: rear port EHC1 controller, port #2 (PR12) @1D12: right-rear port EHC1 controller, port #3 (PR13) @1D13: right-front port EHC2 controller, port #2 (PR12) @1A12: left portSome hardware accessories such as integrated webcam or BT module (part of combo mini-PCIe cards) are also visible @1A15, @1D15 or @1D18. In order to regain full USB functionality, the attached USB2.0 injector (based on Info plist of vanilla AppleUSBEHCIPCI PlugIn of /S/L/E/IOUSBHostFamily kext) reflects the above arrangements with the following settings: 1 x hub PR01 attached to MacBookPro11,1-EH01 USB controller 1 x hub PR01 attached to MacBookPro11,1-EH02 USB controller All 4 x external ports are then fully functional as USB2.0 under EC 10.11. [E6440_DSDT_ElCap10.11_EHCx-patched.zip] [E6440_ElCap10.11_USB2.0_Injector.kext.zip] Edit: See below for a further USB ports update

Did you use the bootpack available here?