Hervé

What's that file?

Did you replace the vanilla kernel by the Haswell-patched version or configure the ASUSCPUPM in Clover to patch the kernel on the fly?

Ok. The DSDT provided in that archive appears dodgy. I can open the file but if I try to compile it "as is", I get all sorts of errors. Can you provide a raw extracted table instead? I could not get it from your very 1st post and I think you reposted the patched version from Jake...

What's your LCD screen resolution?

If your E6540 is of close specs to my E6440, why don't you give the 10.10.2 patched files a try? https://osxlatitude.com/index.php?/topic/7387-dell-latitude-e6440-with-i5-4300m-hd4600-and-1600x900-lcd-mavericksyosemite/page-3&do=findComment&comment=47399 I've also declared the correct Azul FrameBuffer in the DSDT (0x0a260006) and stick to Intel mobile HD 4600 dev id 0x0416: Device (IGPU) { Name (_ADR, 0x00020000) Method (_DSM, 4, NotSerialized) { Store (Package (0x06) { "device-id", Buffer (0x04) { 0x16, 0x04, 0x00, 0x00 }, "AAPL,ig-platform-id", Buffer (0x04) { 0x06, 0x00, 0x26, 0x0A }, "hda-gfx", Buffer (0x0A) { "onboard-2" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } // ... }

That's what your ought to do with kexts, yes. D830n is for D830 nVidia... Just a reference really.

Your system was running fine until you did some EDP tuning, after which, it got screwed for whatever reason. With a fresh install, you'll be Ok again. EDP appears to systematically screw all D Series since the revamp of last summer, presumably because some of the critical kexts are incorrect. I strongly suggest you don't use it for the time being. I've provided you with the files required for the performance tuning, use them. The rest should be standard installation with myHack + bootpack (assuming that one is not screwed up either).

It's explained in the general guide of this site: you place all your necessary add-on kexts in /Extra/Extensions, then run myHack->myFix (quick).

Can you post the result of command lspci -nn instead? The listed USB controller normally works OOB. Make sure it's not disabled in BIOS. For the wireless card, look here. If it's a DW1395/DW1397-like card (chip BCM4312, vend-dev id 14e4-4315), use the patched kext indicated in the list.

Battery icon appears to the Finder bar when you click on the associated case in the Energy Saver PrefPane. If the icon does not stick, you must replace the AppleSmartBatteryManager kext in /S/L/E by the alternative copy I uploaded or use VoodooBatteryManager, but the latter does not always work in Yosemite.

Make sure you have the standard PS2 kext from myHack's generic bootpack at minimum. The pack is found inside the app, in one of the sub-folders.

If you try to manually add a card (by clicking on the + sign), do you see the card in the list? If not, you may have to consider replacing it by a fully supported model.

Which kext did you patch? I assume the AppleAirportBrcm43224 PlugIn of IO80211Family kext in /S/L/E, right? If so and assuming you now see a Broadcom wifi card in the Network PrefPane, check that it is enabled there. Failing that, you may want to undo your patch and try the attached kext or its AppleAirportBrcm4311 PlugIn. It's an old set of kexts, but it always worked for me from SL to Mavericks. Can't remember with Yosemite... Broadcom43XXFamilyrev2.kext.zip

https://osxlatitude.com/index.php?/topic/2120-supportedunsupported-wireless-cards-inventory/

myFix takes care of that...

You should change the hibernation mode to 0 and remove the sleepimage file if there is one. Use the following Terminal commands: sudo pmset hibernatemode 0 sudo rm -f /var/vm/sleepimage For battery status, replace the AppleSmartBatteryManager kext in /S/L/E by the attached version. Finish with the following Terminal commands to fix permissions and rebuild cache: sudo chmod -R 755 /System/Library/Extensions sudo chown -R 0:0 /System/Library/Extensions sudo touch /System/Library/Extensions sudo kextcache -Boot -U / AppleSmartBatteryManager.kext.zip

You can either use Clover or Chameleon. I've detailed both methods.

Well, nothing wrong in your /E/E folder, nothing wrong in your Chameleon boot plist, I have no idea where things got screwed! It would appear you need to re-install the OS, yes... Stay away from EDP. You will need the SMBIOS of the MacBookPro5,1 to obtain native CPU + GPU speedstep.

Chan you check your hibernation mode with Terminal command sudo pmset -g ?

Check your DSDT + Hibernation mode as detailed for the E6440: https://osxlatitude.com/index.php?/topic/7387-dell-latitude-e6440-with-i5-4300m-hd4600-and-1600x900-lcd-mavericksyosemite/

Please! We don't support those tools here. You know where to go... We've published some guides for this OS X version on that laptop, I suggest you read and use them.

You need to boot with NullCPUPowerManagement kext until such time as you've generated your own CPU-specific SSDT using the generator tool and be able to revert to native CPU power management.

https://osxlatitude.com/index.php?/topic/6556-wwan-using-ericsson-f5521gw-hp-hs2340-hspa-dw5550-in-os-x/&do=findComment&comment=47206 No double posts please.

I have just come to notice that BIOS A18 and A19 modify the System Number from -595B to -3A5B. Whilst these latest versions neither bring new particular features nor affect behaviour in OS X, they are however incompatible with unlocking passwords provided by the well-known BIOS password generator tool (Dogbert's tool included in EDP) which only supports System Numbers ending in -595B/-D35B/-2A7B. As such, if your D630 BIOS is locked with an Admin password, you're unable to unlock it if BIOS is above version A17. Please note that having a BIOS Admin password set does not prevent BIOS downgrade from Windows using the package available off Dell's support web site or directly from a USB key using the extracted .hdr file.

After verification, once updated to BIOS A18/A19, D630 laptops get a -3A5B system number trailer. With previous BIOS versions up to A17, the trailer tag is -595B. The BIOS password generator tool only supports D630 system numbers ending in -595B. In addition, unlocking passwords obtained with -595B don't work in BIOS A18/A19. You must downgrade to BIOS version no higher than A17 to be able to unlock your password. I'm now sticking to that version and I suggest everyone does the same. BIOS versions A18/A19 do not bring any new features anyway.