Hervé

Make sure to build your myHack USB installer with your retail SL installation app/package because you did not (myHack screenshot clearly shows 10.6.2). Which version is it by the way? You have to mount the dmg before myHack can use the app. Only retail versions are suitable for installing SL on a Hackintosh, i.e. versions 10.6.0, 10.6.3 and 10.6.8. Non-retail versions do not possess the necessary installation files. This has been indicated on the forum many times in the past and your myHack screenshot clearly showed incorrect SL version + errors with the installation package; you did not pay sufficient attention to that... Your current USB installer is useless. To obtain your legit copy of SL, follow the info posted here. You've seen the BIOS article, but missed the thread about full packs. It's right above it, i.e. here. NB: 1Go of RAM... that's a little short to run OS X, you really should increase that to 2Go minimum. If you can upgrade your CPU to a 64bit Merom T7xxx FSB667 4Mo L2, even better! graphics chip of Intel 945GM chipset is GMA950 http://www.dell.com/downloads/global/products/latit/en/spec_latit_d620_en.pdf

1st of all, Mavericks would be a "downgrade" since it preceded Yosemite. You can "upgrade" an existing installation by doing a fresh installation over the existing one. The new OS will overwrite the existing installation but will retain all applications and user & data files. El Capitan 10.11 is only at beta stage at the moment, so you may want to wait until it's officially released before you install it. I also recommend you make a full back of your existing Yosemite installation (a partition image for instance or a disk clone) before you start anything.

Well, things depend on the partitioning scheme you've used on the HDD. For instance, if it's MBR, you need to apply the MBR patch to install OS X. If GPT/GUID, you're Ok. In terms of format, OS X target partition should always be formatted "Mac OS Extended (journaled)".

Mifune, I appreciate this might be a little difficult, but you need to be specific in terms of the problems you encounter. What makes you say you cannot install on the internal HDD? What error message are you getting, it any at all? One very useful good practice on the E Series is to reset BIOS to default settings and set HDD mode to AHCI before you attempt installing OS X.

This is kind of daft! One hand you say you've installed Snow Leopard on that system and on the other you want to install from Windows because you "don't have MAC". if you have an existing SL installation, then you have a valid base to create a myHack Lion/Mountain Lion/Mavericks or even build a manual Yosemite installer. All you'll need to do then is attempt installation on a separate HDD partition. If you got rid of SL, re-install it.

No obvious reason for the automatic reboot you experience. It most definetelty should be Ok to boot all those OS on your Core2Duo laptop. 'could be something weird with your CPUPM settings but you also said you were using a torrent image, so you never know what you got... It'd be much better to download a legit Mavericks or Yosemite installation package off the AppStore, especially as they cost nothing... For Mavericks, I would suggest to try a myHack-based installation with the default bootpack; it's kind of well-proven on Core2Duo systems.

The device reported in IOReg is 168c/002b, i.e. what I was expecting for an AR5B95 card, but I'm not seeing 168c/0027 at all. Anyway, it should be all ok now with the patch inserted by Jake.

It's probably the line above that erroneous, maybe expecting Arg0 () rather than just Arg0 Furthermore, a Return statement is usually the last one in any part of DSDT code with nohing right immediately after except a closing "}".

There are BIOS tests you could run, but a failed GPU usually gives some seriously distorded/corrupt display and hangs the laptop rather than a plain black screen. If you suspect the nVidia GPU, you can always just bake the mobo into your oven. The process has been described several times on the forum before in the D6xx section. The GPU chip does not totally fail per sé, it's atually a BGA balling issue: http://www.tfixrepairs.com/services/hardware/graphic-card-repairs/ Then the LCD wire/ribbon cable is known to wear as well. This tends to give a blinking or blurred display or missing lines, sometimes a black screen. If you wobble the display panel, it may recover. I've personally experienced such a worn cable on 2 different D6xx models and had to replace the cables. It's wear and tear. These old lappies were very popular and most have endured a good and plentiful life...

Nothing to add, you've done your home work and have pretty good T° for the model.

https://osxlatitude.com/index.php?/topic/7091-dell-latitude-e6420-with-i5-2410m-hd3000-and-1600x900-lcd-mavericks/

Correct Jake, best to stick to a Chameleon version like r2401 for instance. Later versions (like r2700 for instance) do detect HD4x00 graphics and fake desktop HD4600 id 0412. That certainly proved problematic to get graphics acceleration on my E6440, whether with vanilla or patched AzulFB and HD5000Graphics kexts. With Chameleon r2401 and binary patched kexts, no problem, I consistently get QE/CI.

As I said before, you can try and patch the Atheros40 kext but I understand this card to be unsupported. Not much you can do except replace it by a supported device.

https://wikidevi.com/wiki/Dell_Wireless_1705_802.11n_%2B_BT_4.0 -> 'based on AR9565 chip if would seem (PCI ids 168c:0036) and, afaik, that is not supported under OS X. You can try and experiment of course and let us know how you get on. If you were to succeed, please feed back to update our list of supported/unsupported wireless cards. Take your eventual research in the R&D forum subsection, not in this Dell laptop thread where it'll get lost. I advise you to replace that card by a supported model or use a supported USB dongle.

DW1520 is only supported with DSDT injection/kext injector + kext patching: https://osxlatitude.com/index.php?/topic/2120-supportedunsupported-wireless-cards-inventory/

You misunderstand. You don't have graphics acceleration working because, in order to get your HD4400 GPU supported, you need to fake Desktop HD4600 or patch the Azul FB + HD5000 kexts and your DSDT too; HD4400 is not natively supported. Until you do this, you will not get graphics acceleration hence 4Mb VRAM displayed. Once you'll have sorted out your graphics, you'll see that VRAM will automatically adjust because the OS driver will load and allocate VRAM. Only then, may you try to even increase it more by adjusting/experimenting with FB values but you would normally find it's not necessary. Read RampageDev's blog for HD4400 and adapt for your mobile HD4400. Guides have been posted here about this too. To summarize, if you get graphics acceleration working, you'll see your VRAM allocated (and increase from 4MB), it's not the other way round...

Until we know what wireless you have, all we can say is use a compatible one (or a version that can be used with patch kexts).

Check the T-junction T° of your CPU on Intel ARK site and adjust the Tjmax parameter inside Info.plist of CPUSensors kext (it's a plugin of FakeSMC) accordingly if necessary. It's kind of rare to require this adjustment these days but if Tjmax does not detect real T-Junction T° properly, it can give false readings...

You may want to open up the laptop to clear any eventual dust clog from the fan radiator and renew thermal paste of the CPU. This may improve T° readings a little or a lot.

Easiest way is to use HWmonitor app that comes with Kozlek's FakeSMC package. The app will display real-time CPU throttling. But maybe you use that already. If you want to experiment with AGPM (GPU throttling), see here.

Updated Ok to 10.10.4, using exact same kexts replacement as for 10.10.3 and same AMD kernel from Bronya.

It's been totally safe to update through AppStore for quite some time. Now, bear in mind the eventual and/or usual safety measures: on Sandy/Ivy Bridge platforms with Chameleon, reinstate NullCPUPM before reboot as AICPUPM will need rematching to avoid KP on Haswell platforms with Chameleon, patched kernel will be required to avoid KP/reset

Check that CPU power management works and that you've got GPU power management too.

Should be a no-brainer on most machines. Should work OOB on C2D/C2Q/Arrandale systems. Sandy/Ivy Bridge systems will need to re-instate 10.10.3 patched AICPUPM kext to avoid KP (or use null CPUPM). Haswell systems will need the patched kernel. As usual, this applies to Chameleon-based Hackintoshes, Clover-based models being able to call on built-in on-the-fly patches. Great news for SSD owners: 10.10.4 introduces a feature to enable trimming on non-Apple SSD, at last! sudo trimforce enable That's it, that's all, SSD trim patch can now be considered a thing of the past.

Bluetooth patch In the case of DW375, simply add the following entry to the Info plist of BroadcomBluetoothHostControllerUSBTransport plugin of IOBluetoothFamily kext: <key>Dell DW375: PID 33159/0x8187, VID 16700/0x413C</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string> <key>IOClass</key> <string>BroadcomBluetoothHostControllerUSBTransport</string> <key>IOProviderClass</key> <string>IOUSBInterface</string> <key>LMPLoggingEnabled</key> <true/> <key>IOProviderClass</key> <string>IOUSBDevice</string> <key>idProduct</key> <integer>33159</integer> <key>idVendor</key> <integer>16700</integer> </dict> Always patch from the current version of the kext as Apple as a long tendency of modifying its Bluetooth/USB kexts at each release. Previous kext versions are usually not compatible, so you cannot usually port a previous patch from an earlier OS X version.