Hervé

Actually, tuning the system for optimised performance in terms of CPU + GPU throttling is much better than disabling AGPM altogether (which is a bit harsh) and will avoid unnecessary heat and battery consumption. Given the well-known fragility and eventual inevitable failure of the nVidia GPUs on those Latitude D laptops, I would actually strongly discourage disabling AGPM... https://osxlatitude.com/index.php?/topic/2673-performance-tuning-with-fakesmc/ https://osxlatitude.com/index.php?/topic/7807-nvidia-gpu-performance-tuning-with-agpm/

Yes, as detailed in post #2 of this thread: 1) you format your target Windows partition/space from OS X as "MS-DOS (FAT)" or "ExFAT" 2) when you begin Windows installation, you 1st reformat that Windows partition as "NTFS"

I can see your SD card reader at RP08@1C,7 listed as device id pci1217,8520. The DSDT patch should therefore work since it's the exact same hardware as on the E6440, located under the same DSDT device and at the same address. Did you check that it's not disabled in BIOS settings? One other thing I've noticed is that I renamed the original Device (PXSX) to Device (SDXC) in my patch, whereas your IOReg shows the original PXSX device and no AppleSDXC kext loaded. I'm pretty sure I did this renaming in a 2nd stage once the 1st patch (compatible statement added) was proved successful, but I would suggest you try and rename your device as per the linked patch above. I would also check that you don't have a typo in your DSDT patch. My E6440 IOReg: Your E6540 IOReg:

Mmm, I'm pretty sure I've experienced this before but cannot remember the context... I've just checked Airdrop between my E6220 and my E6440, both fitted with AR5B93 cards and Airdrop appears to work Ok with or without BT enabled (and I don't have BT4.0 modules: E6220 has DW375 and E6440 has Intel N-6205); I was able to transfer files from one another without issues.

Please guys, can we avoid creating multiple threads on the same matters? We already got several E6420 threads opened up these last few days and at least once with trouble on the nVidia model.

Repair permissions and rebuild cache.

Doh... you obviously would not be able to boot OS X off a USB key that has only the Chameleon boot loader on it!!! Boot your OS X installation via the USB key! When you see the moving character at the top left corner, press F8 to interrupt the Chameleon boot process, select your Yosemite HDD partition in the listed disks, and just press [ENTER].

Quotes from the article: 8) At the bottom of the Keys list, open down REV, RVBF and RVUF. By default, FakeSMC is using SMC version 1.30f3 which is displayed in Data field as 01300F00 0003. Mario and I tried the SMC version listed for the 15″ MacBookPro5,1 -> 1.33f8 (SMC 1.2). This translated to 6bytes Data 01330F00 0008. The value required for SMC key 1.54f33 should be be doddle to establish now... This being said, your above value 1.54f36 may work.

AICPUPM = AppleIntelCPUPowerManagement kext NullCPUPM = NullCPUPowerManagement kext Sandy Bridge and Ivy Bridge-based laptops require a patched AICPUPM kext to avoid KP at startup. Failing that, the NullCPUPM kext can be used until the patched kext is installed. Patched versions of the Yosemite AICPUPM kext are available here. You can remove the DropSSDT=Yes until you generate your own CPU-specific table.

After installation has completed, the vanilla kernel is on your freshly created Yosemite installation. As such, you need to boot into the USB installer and copy the Haswell-patched kernel to the HDD before you can boot it. Failing that, indeed, you experience system reset when kernel loads. The above is actually in the guide, though I admit after having created a Clover USB key, installed and booted OS X. You may find the steps of this guide a little easier to follow. You'll obviously have to copy the Haswell-patched kernel to target Yosemite HDD just before copying the Extra folder.

No, "dart=0" is not a default Chameleon settings. You obviously have that configured in your org.chameleon.Boot.plist in /Extra. Check that file, it may have other options that cause trouble. If you generated your CPU-specific SSDT from a different machine, I'd say look not further. Remove that table from your E6420 as it's probably incorrect. You can safely boot without it, either with patched AICPUPM kext or with NullCPUPM. Once you'll have booted your E6420 to OS X desktop, then you'll be able to generate your SandyBridge-related SSDT.

REV, RVBF abd RVUF are SMC keys; in the case of iMac11,1 SMBIOS profile, change those keys to 1.54f33 as advised above. If you carefully read the article again, you'll suss it out. Normally, it's obvious to the eye... For smc-compatible parameter, it's smc-piketon, not sms-piketon. You need to do the tuning in full, don't do a half-job. Half-jobs don't work...

Let me repeat: you can't run myHack to make a USB installer from Leopard and you can't either from Yosemite and beyond (at time of writing). So, Mac OS X/OS X versions that support myHack: Leopard 10.5 = No Snow Leopard 10.6 = Yes Lion 10.7 = Yes Mountain Lion 10.8 = Yes Mavericks 10.9 = Yes Yosemite 10.10 = No El Capitan 10.11 = No Furthermore and to make things easier (!), you need to use myHack v3.1.2 to create a SL USB installer. For subsequent OS X versions, you can safely use myHack v3.3.1.

??? You said you were running Lion... Now you talk about updates for 10.5.8? Are you running Leopard? This is a version we don't support here, it's too old. Most Hackintosh sites no longer do either. You'll have to get up to SL through other means such as Nawcom's ModCD/ModUSB before you can build a myHack USB installer. Then I suggest you keep that USB key safe somewhere. Since you already run Leopard, opt for the ModUSB, that'll be easier: 1) restore your SL retail disk image to a USB key 2) run ModUSB to make it a bootable installation key 3) copy the D520 bootpack as /Extra folder on the USB key

Unlucky... You need SL at minimum for myHack. You know the full range now!

SD card should work with DSDT patch detailed in my E6440 guide...

myHack is not supported in Yosemite and beyond.

I know no other solution to boot your OS X partition, no.

Those commands rebuild the kext cache/prelinked kernel.

Try safe mode, adding -x flag to the above ones. Failing that, no idea... What updates did you install? I'm not aware of any 10.7.5 updates that broke a D620/D820 installation, one based on myHack at least... Maybe you'll have to re-install Lion totally.

Just boot your OS X installation through your USB installer and once you're into OS X, reinstall your Chameleon bootloader. Basically the Windows installation overwrote the boot sector; that's normal.

myHack cannot/does not/will not patch AICPUPM. In fact, you don't need a patched AICPUM kext on your CPU; the patched kext only applies to SandyBridge/IvyBridge CPUs. What you need is proper CPU power management, which you do not appear to have and won't as long as you use NullCPUPM. Tune your system through FakeSMC kext tuning + appropriate SMBIOS profile. Read this for details. Target whatever iMac profile is best suited to your system. You can use the list of available profiles provided in Chameleon Wizard app or the specs listed at everymac.com for each Mac model to help you choose. Lynnfield-based iMac models included iMac 11,1 and iMac 11,3. For iMac11,1: SMC keys=1.54f33 smc-compatible=smc-piketon You should be able to obtain native sleep/wake thereafter and without any need for SleepEnabler (which is only required if you use NullCPUPM).

USB ports availability don't just depends on DSDT (re)patching of EHCx devices to EHC1/EHC2. It also depends on the SMBIOS profile you use as that determines the USB ports # that will be supported. So please specify what you use in that respect.

No, you can't undo the update, especially if it has not fully completed, which can be the case until 1st post-update reboot has completed. Try and boot in verbose mode and without cache (i.e. boot with flags -f -v) to see if it'll boot to completion or see where it stops.

The DSDT will be the same as for previous OS X versions. For EC, you just have to check the USB devices and rename them if required to EHC1, EHC2.