Hervé

For your wifi card, check the Mediatek web site. Make sure to identify your exact wireless chip beforehand. For graphics, if you cannot disable one of the GPU from BIOS, you can move/remove (but keep a backup) the nVidia kexts from /S/L/E so that only the Intel kexts will load. Of course, you'll have to patch things for your HD4400 to be recognised and work properly as there is no native support for it. It's pretty much the same story as the mobile HD4600 (id 0x0416): you either pretend to have a desktop HD4600 (id 0x0412) or you patch (including binary patching) the Azul frame buffer kext. There are several threads on this very matter on the forum.

Post your raw IOReg output + raw DSDT. But, in all likelyhood, you'll need to re-instate those nVidia kexts you removed.

No doubts to be had on this matter; Ravven's signature shows "AR8151", which is in line with the product ids found in the Info.plist of his posted kext: <string>0x10831969 0x10631969 0x10621969 0x20601969 0x20621969 0x10731969</string> 0x10831969 -> Atheros AR8151 PCI-E Gigabit Ethernet controller 0x10631969 -> Atheros AR8131 PCI-E Gigabit Ethernet controller 0x10621969 -> Atheros AR8132 PCI-E Gigabit Ethernet controller 0x20601969 -> Atheros AR8152 PCI-E Fast Ethernet controller 0x20621969 -> Qualcomm Atheros AR8152/8158 PCI-E Fast Ethernet controller 0x10731969 -> Atheros AR8151 PCI-E Gigabit Ethernet controller In addition, Asus web site provides an Atheros AR8151 driver in the support section of the X73SV laptop model. I will modify the original guide to that effect in order to avoid further confusion in the future. As a final conclusion, this Atheros kext is clearly not applicable to a Realtek chip, which should not have been a surprise from the onset since we're talking about a different manufacturer altogether. There remains no known OS X driver for the Realtek RTL8151.

Your DSDT errors are due to syntax errors. It could be that the editor you've used has smart quotes activated, in which case, disable that from the System PrefPane to avoid such issues with compilation. But, you could also have a missing or misplaced comma/bracket/quote character. You need to backtrace the errors with provided line numbers. Post your raw DSDT and we'll have a look.

I think Ravven confuses Realtek RTL8151 with Atheros AR8151 (as per his signature)... But until someone decides to post the PCI ids, we can't confirm. Here's what I've found so far: Realtek RTL8151: ven=0x10ec, dev=0x8151 ? (-> not covered by AtherosL1cEthernet kext) Atheros AR8151: PCI-E GigaEthernet LAN, ven=0x1969, dev=0x1083 (-> covered by AtherosL1cEthernet kext)

These Intel X5550 are quad-core Xeon Nehalem; make sure to use the correct SMBIOS profile. I'd start with MacPro3,1 and avoid the MacPro4,1 (even though that specific model did ship with X5550 CPUs) as much as possible as this profile/model is known to cause issue 5KPs) with nVidia graphics cards. But you can circumvent that. I'd need to look that up once more, all the details elude me right now. From memory, myHack does warn about it.

GeForce G210 normally works with a simple GraphicsEnabler=Yes. If the card still does not register, you may have to patch your DSDT to add the card's details. You'd 1st extract the data from the output of IOREgistryExplorer app.

Last update: 02 Apr 2018 EDP being in semi-permanent revamp, here are full packs for the Latitude D820/D830 series. The packs do not require any subsequent EDP tuning at all, they provide everything required to obtain a fully working system (CPU power management, graphics, LAN, audio, keyboard, trackpad), non-OOB wireless, bluetooth and any other devices excluded of course. However, some manual tuning for proper Sleep/Wake operation is required: setting hibernation mode to plain old sleep and deleting any eventual sleep image file. This is done through the following Terminal commands upon final OS X installation: sudo pmset hibernatemode 0 sudo rm -f /var/vm/sleepimage Vanilla support stops at Lion 10.7.5 for the Intel GMA based models and the D820 nVidia due to drop of GPU support in subsequent versions. For those systems, ML may be installed and tuned back to 32bit operation through MLPF hack. Look at the Supported models with guides forum subsection for MLPF-ed ML guides and packs. Only the D830 nVidia supports vanilla installation of Mountain Lion and subsequent versions (Sierra and later require Penryn CPUs). For all models, read the Performance tuning thread for CPU + GPU tuning if required but the FakeSMC kext included in the packs below brings it all. D820 GMA950 LoRes (WXGA 1280x800): coming up - D820 nVidia Quadro 120M (all res): coming up - D830 GMA X3100 LoRes (WXGA 1280x800): SL coming up D830_X3100_LoRes_Lion.zip D830 GMA X3100 HiRes (WSXGA+ 1680x1050 & WUXGA 1920x1080): SL coming up D830_X3100_HiRes_Lion.zip D830 nVidia Quadro NVS 135M/140M (all res): SL and Lion coming up D830_NV135M_ML_Extra.zip D830_NV135M_Mav_Extra.zip Yos coming up D830_NVS135M_EC_Extra.zip D830 nVidia Quadro NVS 135M/140M (all res) + Penryn CPU: D830_NVS135M_Sie_Extra.zip NB: For Chameleon-based Yosemite installations (i.e. no Clover or otherwise), not all kexts load from /E/E. Eg: VoodooHDA + HDADisabler or lspcidrv. In such cases, copy the kexts to /S/L/E and rebuild the cache with the following Terminal commands: sudo chmod -R 755 /System/Library/Extensions sudo chown -R 0:0 /System/Library/Extensions sudo touch /System/Library/Extensions sudo kextcache -Boot -U / Enoch-rev.2839.pkg.zip

Up to DB2 through the AppStore update; it's a biggie of 2Go...

I'm afraid there's no solution to the iMessage issue under Chameleon for the moment (unless you could steal the read id/serial numbers of a Mac). Apple did change its own security system and the NVRAM module solution is no longer effective. You'd probably have to switch to Clover to have any hope of recovering use of that app.

I've posted full packs that do not require EDP in my Vostro200 thread. You can use that.

If you're using Clover, you probably were not using any patched kexts but faking desktop HD4600 GPU id. Try to boot without cache to begin with.

Guys, please provide your LAN card PCI ids (Vendor + Device). That'll be available through lspci -nn Terminal command (if you have the lspci driver + binaries installed) or DCPIManager app.

If you were using patched kexts in /S/L/E before your update, you'll have obviously lost that after the update. You would then need to repatch the graphics kexts that were installed by the update (most notably the AzulFramebuffer kext)

There are examples of what to do here. This was all based on Chameleon installation, not Clover which may overwrite some of those settings...

Sounds like a cache issue. Try to boot Chameleon with -f flag.

Check the various USB devices in the DSDT, they may also have to be renamed into UHC devices. Changing EHCI to EHC1 may not be sufficient. Following such advise from Polyzargone at IM, I'm about to verify this on the D630. Meantime, try this new one where all USBx devices are converted to UHCx devices: E6400_DSDT.aml.zip

You should post your files for the benefits of others.

Afaik, you can only run off the HD4600, the discrete AMD GPU is not supported (yet?).

Jake has posted several posts about the method to fake desktop HD4600 GPU (id 0x0412) with kexts. I'm sorry I don't have links at hand but you'll find them in the guide section or through the Search engine. You can also consult my E6440 Mavericks/Yosemite guide which fully details the methods I followed to patch the Azul frame buffer kext to support the mobile HD4600 GPU (id 0x0416). The exact same principles will apply to your HD4400. PS: afaik, Chameleon boot parameter "IntelAzulFB=xxx" is ineffective with Yosemite. With my E6440, it worked perfectly with Mavericks, never with Yosemite. I had to patch the DSDT.

That's quite normal, but can you confirm you reached the Yosemite desktop? You now need to finalise tuning to obtain graphics acceleration. You could do that either by faking HD4600 Desktop or by patching the graphics kext.

Again, all the necessary kexts and files are in the D630 pack I posted... You don't need EDP, which happens not to work at this time.

You probably have the wrong DSDT with unsuitable graphics settings for your particular LCD. What's its resolution?

No reason why it would not work. You can use my E6440 guide and adapt if necessary. I've linked to it on post #52. It'll depend on your own system's specs but it should be very similar to the E6440.

You need to set up the clover config.plist correctly for your own model, depending on specs. Could mean unselecting all DSDT fixes, selecting (or not selecting) kernel and/or AICPUPM patch, etc. I still haven't managed to boot the Clover USB installer on my C2D-based D630 either...