Hervé

Some Latitude E Series (like the E6440) require a 90W adapter. Check whether this applies to the E6520. Nothing wrong with your kexts or config.plist. At this stage, on the basis that you're getting POST messages about it, I'd suspect your adapter is not suitable...

Raw (uncompiled) ACPI code should be in files with a .dsl extension. Compiled ACPI code is contained in .aml files.

A few questions... What makes you think your patched DSDT is not loading? Which bootloader are you using? -> Chameleon/Enoch will always expect a file called "DSDT.aml" (or "dsdt.aml") in /Extra by default; that can of course be manually overwritten whether manually by interrupting the bootstrap or specific entry in o.c.B.plist file. -> Clover will always expect a file called "DSDT.aml" (or "dsdt.aml") in /CLOVER/ACPI/patched by default; again this can be overwritten through menu item of specific entry in config.plist file.

Maybe it's not DSDT related then. Can you please post the list of kexts you're using and detail of your SMBIOS + boot plist (whether Chameleon boot plist or Clover config.plist)? What kind of power adapter is it by the way? 45W, 65W or 90W ?

Text files for DSDT patches should be created or edited with a basic editor such as TextEdit or vi (from command line); this is to ensure that no application specific format is added to the file.

Yup, all details here.

There you are. That one should fix your AGPM throttling issue. Let us know. FakeSMC_AGPM-for-NVS-140M.kext.zip

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.