Hervé

https://osxlatitude.com/index.php?/topic/8368-e6420-intel-hd3000-el-capitan/page-3&do=findComment&comment=58435

Lookup RampageDev's guides on his blog.

You do not need the patched AICPUPM kext on a C2D system. The patched kext is only to avoid the CPU power management issue (Kernel Panic) related to BIOS-locked MSR register on Sandy/Ivy Bridge systems. It'll not change anything for your apparent Shutdown/Restart issue for which you may have to implement a DSDT patch. As stated before, all you need for proper/native CPU power management is: the correctly tuned FakeSMC kext (which you now have) the proper SMBIOS profile (which you now have) C States + P States generation enabled in bootloader config (which you should have enabled by now) no NullCPUPM (get rid of it if still in use)

Black screen issues gets solved by using the above SMBIOS.

I guess you meant the CPU-specific generated SSDT, not the DSDT, because the latter would not vary according to CPU.

These error messages indicate incorrect permissions... Did you check your PM?

Guys, if the Clover method appears to be so troublesome, why don't you switch to Enoch with BIOS in legacy mode? When I see the ton of recent posts on getting Clover to work in UEFI mode in these laptops, I can't understand why people stick to a method they clearly don't fully master.

I've updated the D620/D630 pack thread with the ML 10.8(.5) pack. Tested and verified with a USB2.0 myHack v3.3.1 installer all the way through, so you can use it in full confidence. If you use a USB3.0 key and get USB-related error messages followed by "Still waiting for root device", just unplug your USB3.0 installer and replug it; the installation will then continue. When you create your USB installer, proceed as follows with myHack v3.3.1: 1) create ML10.8 installer 2) install myhack utilities 3) install Extra (my own, pointing to downloaded ML10.8.5 pack) 4) remove problematic extensions 5) install Chameleon

USB issues under El Capitan are well-known and the fixes well-documented. You'll find the necessary information through a Google search or a search on the forum.

Remove those kexts added to /S/L/E and copy them to /Library/Extensions. Then repair permissions and rebuild your cache with following commands: sudo chmod -Rf 755 /Volumes/<USB installer name>/S*/L*/E* sudo chmod -Rf 755 /Volumes/<USB installer name>/L*/E* sudo chown -Rf 0:0 /Volumes/<USB installer name>/S*/L*/E* sudo chown -Rf 0:0 /Volumes/<USB installer name>/L*/E* sudo touch -f /Volumes/<USB installer name>/S*/L*/E* sudo touch -f /Volumes/<USB installer name>/L*/E* sudo /Volumes/<USB installer name>/usr/sbin/kextcache -Boot -U /Volumes/<USB installer name> -K /Volumes/<USB installer name>/S*/L*/Kernels/kernel This assumes you've copied the appropriate Yosemite kernel file to /S/L/K.

Seems you're not using boot option kext-dev-mode=1; that's mandatory with Yosemite.

Sounds like you have no graphics acceleration. You're going to have to tell us more if you hope to get some support. post your system's specs detail how you installed OS X specify the boot loader you're using post your pack

Copy your add-on kexts to /Library/Extensions, repair permissions and rebuild your cache. Chameleon will not inject or load kexts from /E/E if i remember well...

The Qualcomm Atheros BT module may not actually be CSR based (CSR was only acquired by Qualcomm last year). You could undo the CSR kext patch and do the same for the IOBluetoothControllerUSBTransport kext.

Oh! I think you kinda screwed the CSR controller transport kext with your patch there! My guide says to add a new entry by copying and modifying an existing entry, not to wipe out everything! Anyway, try the attached patched kext instead. Simply overwrite the existing PlugIn kext inside IOBluetoothFamily kext, repair permissions, rebuild cache and reboot: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo touch -f /S*/L*/E* sudo kextcache -Boot -U / (or sudo kextcache -system-prelinked-kernel) Good luck. CSRBluetoothHostControllerUSBTransport.kext.zip

No reason why you these latest BIOS would not work. I would not use a MacPro SMBIOS profile on this machine but an iMac one instead. iMac 10,1 would look good to me. It's a machine of similar specs to my old Vostro 200, so you should be able to re-use some of the settings used on that system. But I never use Clover of course...

This Clarksfield i7-740QM CPU bears no integrated 1st gen Intel HD graphics, so you need to get that ATI Firepro M7820 supported. As stated by Bronxteck, it's indeed very similar to the Radeon HD 5870. You may have to use boot option GraphicsEnabler=No and safe mode (i.e. -x flag) to begin with and basically boot without graphics support. You may then try to get graphics acceleration by experimenting with various ATI framebuffers and settings as described by RampageDev for the ATI 5000 Series. I've read reports of people reaching success with Nomascus framebuffer and ports set to 3. Identify your graphics card PCI ids, you may have to patch the AMD kexts with them.

First of all, we recommend that you use myHack with the D630n bootpack. Should the available bootpack posted on the compatibility chart turn out invalid, I invite you to use the Mavericks pack I posted here. You'll have to add the SL 10.6.8 ACPIPlatform kext (v1.3.6) as that is required for Lion and ML. The kext is available in the Lion full packs I posted at the same place.

Can you check your BT module PCI ids in SysProfiler. In IOReg, I see vendor 0x13d3 and device 0x3362. That would make it Atheros AR3012 (part of some AzureWave device?).

Can you please post your full /Extra folder?

Please post your DSDT.

Correct, that's how one should proceed. You start with the minimal possible pack then add things one by one. It's timely, it's frustrating, it's exhausting but it's the only way to get things right.

Ok, here's a (very recent!) guide. Follow the same method: identify your BT module's chip and patch the appropriate kext accordingly.

The BT4.0 module of the Intel Advanced-N 6235 (ven:dev id = 8087:07da) is supported OOB under OS X. However, it cannot be turned on or off by default. As usual, this requires patching of the appropriate Bluetooth controller transport kext. Here's what to do (illustrations under El Capitan 10.11.3): Patch attempts of the generic IOBluetoothHostControllerUSBTransport kext lead nowhere. However, on looking for the hardware specs of the BT device, it turns out to be a CSR-based module (Google is our friend!). The CSR controller transport kext can then be patched. PlugIns of OS X El Capitan 10.11.3's IOBluetoothFamily kext are as follows: E6440:~ admin$ cd /System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/ E6440:PlugIns admin$ ls -la total 0 drwxr-xr-x 9 root wheel 306 Mar 11 21:49 . drwxr-xr-x 8 root wheel 272 Jan 20 15:25 .. drwxr-xr-x 3 root wheel 102 Nov 14 05:31 BroadcomBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 CSRBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 CSRHIDTransitionDriver.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothHostControllerUARTTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothSerialManager.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothUSBDFU.kext E6440:PlugIns admin$ Here, the kext to patch is CSRBluetoothHostControllerUSBTransport. It's a simple matter of editing the Info.plist file of the kext and add a new entry based on an existing profile. In this case, a copy of the ApplePortableModule entry can be pasted and edited as follows: <key>Intel-N6235</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.iokit.CSRBluetoothHostControllerUSBTransport</string> <key>IOClass</key> <string>CSRBluetoothHostControllerUSBTransport</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>idProduct</key> <integer>2010</integer> <key>idVendor</key> <integer>32903</integer> </dict> NB: 0x07da (hex) = 2010 (dec). 0x8087 (hex) = 32903 (dec) The modded kext can then be placed back in the PlugIns folder of the IOBluetoothFamily kext, permissions repaired and the cache rebuilt. On reboot, the CSR USB Transport kext is loaded and the BT module can be turned on or off through the Finder's bar icon (and it switches the BT led on or off too, well at least on my E6440): An alternative to patching the vanilla kext is to add the entry to FakeSMC's Info.plist. It's also sustainable to updates within a given OS X/macOS version. NB: Only the Bluetooth module of this card is supported, the wireless module remains of course unsupported in OS X/macOS as per all Intel cards.

Since Bluetooth appears to work OOB, you should be able to turn it On and Off through the BT Finder's bar icon once you've patched the associated Bluetooth controller transport kext. Look in your SysProfiler for the module's PCI ids, identify the BT chip it is based on and patch the associated controller kext. It's always worked for me on the Latitude D and E Series for CSR devices. I've posted several posts on this matter but that was ages ago and can't remember where or when. Try a search on the forum.