Hervé

Make sure AppleHDA gets loaded as the patches will only apply if the kext is cached. If it gets loaded, rebuild the cache: sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / ALso, please note that the 8319D411 patch is not valid in Sierra. Target 8A19D411 instead. The others should be Ok.

Clover on-the-fly patches operate on cached kexts only. It's a mandatory pre-requisite.

I've had some doubts about those above AppleHDA patches/patch combination because they've never worked on my E6220. Yet, it's fitted with IDT 92HD90 audio, i.e. the same as the other E6x20 models. I don't use Clover so I patch my AppleHDA kext directly and here are the details of what I use for Sierra: Find: 8B19D411 Replace by: 00000000 (2 occurrences) Find: 8419D411 Replace by: E7761D11 (2 occurrences) I cannot find any instance of 8319D411 in AppleHDA v276.26... For those who want to try, here are the dummy HDA + pre-patched AppleHDA kexts. AppleHDA_IDT92HD90.kext.zip Patched_Sierra_AppleHDA_v276.26.kext.zip

Are you sure you patched the right device? Please post your DSDT + IOReg output.

Post your laptop specs to be sure but I see you're using MBP11,2 SMBIOS profile so this is probably a Haswell system. 2 things to keep in mind: 1) select KernelPm option (for CPU power management through the kernel); option AsusAICPUPM is for SandyBridge/IvyBridge systems only. 2) make sure you run the vanilla AppleACPIPlatform kext

Typo in the code line now fixed (Ericsson ven id is indeed 0x0BDB as listed at top of thread) but it's a pure cosmetic info so typo had no effect whatsoever. DPCIManager only lists devices on the PCI bus so it's perfectly normal that you do not see the WWAN module since it is USB. I still have my module somewhere, so I'll try to dig it out and test again in EC 10.11.6 and Sierra 10.12 (Sierra retained same version v1.4.0 of CellPhoneHelper kext) but I definitely had it going when I tested it under 10.11.2.

Nope, you need a FSB800 CPU. I you install a CPU of higher FSB it may not be supported and if it were, it'd run at reduced speed (200 x multiplier). T8x00 are not great performers due to their smaller 3Mo L2 cache (4Mo on your T7700). T9x00 are much much better with 6Mo. It makes a big difference.

Maybe something similar to the old RTC issue which reset CMOS. Try and look for the El Capitan RTC patch (DSDT and/or AppleRTc kext).

@offficial_florin: no double posts please. And you can't downgrade OS X, you can only re-install from scratch.

Please note that you cannot proceed with Sierra if your D830 is fitted with the Merom T7700 listed in your signature. Sierra needs a CPU with SSE4 capabilities so you'd have to upgrade to a FSB800/SantaRosa Penryn CPU of the T8x00 or T9x00 families.

Clover will allow you to simply update by running the Sierra installation app. Most things that worked under EC should work under Sierra. There will be exceptions like your audio control buttons for instance. If you only have that machine and cannot sustain to lose it, I would recommend you create a separate partition for Sierra or, should you wish to upgrade your existing setup, make a clone of your existing EC partition. Failing that, update to 10.11.6 and wait until other people report their own Sierra experience on this E5450 model.

Webcam is usually USB internal. Check if it's reported in your SysProfiler. If it is, your USB ports are working but the camera may not be supported. As for audio volume and mute buttons not working, it's not something specific to your E7440, it affects all Hackintosh. It obviously results from changes Apple made to ACPI handling in Sierra.

You can look up existing guides for this model. Here, here or here for instance.

Boot stage graphics glitches get fixed with the following IOGraphicsFamily kext patch: Find: 0100007525 Replace by: 010000EB25 Can be done through binary patching or Clover on-the-fly patch.

Means the patch needs to be revised to match your own audio hardware arrangements. You'll have to follow the AppleHDA patching guide (look it up on the forum) and dump your codec data through Linux.

This patch should work as is for all E6x20, E6x30, E6x40 and other same generation Latitude laptops. Don't change the PCI ids to your own card reader's, it would not work since you'd be injecting your own existing ids so it'd be like telling your left arm it's the left arm. You must keep pretending to have Apple's own hardware, that the whole essence of the patch. The patch works on my E6220/E6230/E6440.

With Enoch, you'll be to proceed by temporarily setting your SMBIOS to MBP7,1, download Sierra, install it with MPB7,1 SMBIOS and then, once you're finished, set the SMBIOS back to MBP5,1. You may not get graphics acceleration with MBP7,1 SMBIOS but this will be regained after reverting to MBP5,1 SMBIOS. That's my personal experience on my D630. Apparently you cannot use MBP5,1 SMBIOS with Clover so you may want to stick to Enoch on that particular laptop. Edit: You can also permanently retain MBP7,1 SMBIOS by re-tuning your FakeSMC keys to 1.62f6 (keep smc-compatible set to smc-mcp) and the AGPM patch to MBP7,1 model.

Indeed, it's required on all laptops with Intel 945 chipset, otherwise they KP. But it's not required on laptops with Intel 965 chipset. 'wondering if the OP's clock slippage could be fixed with setting the bus speed to 200000. If D830 is fitted with a Merom CPU, he should also ensure IDA is disabled in BIOS.

Check that: you're not using NullCPUPowerManagement you've not selected P States + C States generation in your bootloader config you've selected a SMBIOS profile suitable to your system (i.e. MBA5,2 or MPB9,2) you've generated your CPU-specific SSDT using Pike R Alpha's generator script you've placed the generated SSDT in EFI/Clover/ACPI/patched folder of your EFI partition

So nVidia GeForce 840M defined under device PEGP within RP05@001C0004. You should modify the _WAK method so that it turns off the dGPU. Right now it wakes it so even if you disable the dGPU at startup, a wake will re-enable it. In SSDT-9.aml, you have a method EPON that must have been modified since I see it set ONOF to Zero. I would have expected it to set ONOF to One. I'd have kept it that way and created a new method called EPOF that does set ONOF to Zero. So you'd have the following code under \SB.PCI0.RP05.PEGP: Method (EPON, 0, Serialized) { Store (One, ONOF) Return (Zero) } Method (EPOF, 0, Serialized) { Store (Zero, ONOF) Return (Zero) } ` You may then modify the _WAK method in DSDT to the following: Method (_WAK, 1, Serialized) // _WAK: Wake { If (LOr (LLess (Arg0, One), LGreater (Arg0, 0x05))) { Store (0x03, Arg0) } WAK (Arg0) ADBG ("_WAK") If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { // Remove those lines since there is no Device PEG0 in any BIOS tables // If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON)) // { // \_SB.PCI0.PEG0.PEGP.EPON () // } If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) { \_SB.PCI0.RP05.PEGP.EPOF () // disables dGPU at Wake } [...] and make sure to add the following at the top of the DSDT under the _SB_.PCI0.RP05.PEGP.EPON external method declaration: External (_SB_.PCI0.RP05.PEGP.EPOF, MethodObj) // 0 Arguments (from opcode) ` Now, in order to load your patched SSDT files, you've got to revise the names you used because the SSDT will only load in the order SSDT, SSDT-1, SSDT-2, SSDT-3, ... Right now, only the SSDT.aml will load and I doubt any of your patched SSDT-6/-8/-9/-10 actually do do. Check through verbose mode.

An IOReg output maybe?

Try the USBinjector kext I created for my D630. It's available in the 10.11 pack I posted here. I would have expected it to work for the D830 too. It needs 2 x pre-requisites: 1) that the USB2.0 controllers are renamed from EHCx to EH0x in the DSDT 2) that you use SMBIOS MacBookPro5,1 profile If you have those pre-requisites in place and remain unable to get all your USB ports to work, then do the following once OS X has booted: run IORegistryExplorer scroll down to USB section plug a USB key in each port and take a note of the port under which your USB key appears edit the USBInjector Info.plist file to adjust the ports according to the list you've just made

No, to run patched AppleHDA, you need: 1) to inject the correct HDEF layout through DSDT patch or via bootloader 2) load the codec definition kext (AppleHDA_ALC280 in your case). Ideally, place it in /Library/Extensions. 3) binary patch /S/L/E/AppleHDA, either through Clover on-the-fly patch or via actual binary file patching You will need to repair permissions and rebuild cache for your change to operate. DO NOT replace the AppleHDA kext of /S/L/E by the codex definition kext. You'd lose all ability to run Apple HDA.

https://osxlatitude.com/index.php?/topic/9248-working-sleep-on-intel-hd-and-nvidia-nvs-on-dell-latitude-e6430-optimus-enabled-or-disabled/

DCPIManager shows id 10EC0280 -> it means that the actual codec of your ALC3220 audio chipset is ALC280. That's what you'd need to look for in terms of AppleHDA patch.