Hervé

Once had a similar problem with a 2nd hand DW1490. Turned out the main antenna socket was no longer properly soldered to the card and one day I found the antenna cable in the air with the socket still attached to it. Card was basically goosed and went straight to the bin.

Add boot flag -v and tell us where it stops.

Check your BIOS setup and adjust if necessary as per recommended settings in dedicated pinned thread in this very section. I take it you're using the bootpack that corresponds to your model, right? Because that black screen is a typical result of having no DSDT or the wrong one on a D630. If in doubts, double check your BIOS setup Information pages.

BIOS A11 should do, but I'd recommend you update to latest BIOS which is A16 if I'm not mistaken. You could also look at upgrading your CPU as you may find that this little T7250 is a bit weak performance wise...

Well, according to the log, you should have a DSDT.aml file in /Extra. Isn't it the case? There sure is one in the bootpack, so if EDP appears messed up, use the files from the bootpack.

Ok, so it's one step at a time then... Any chance of the DSDT now?

Seeing the hardware is one thing... having it fully working can be quite another... Seeing hardware does not equate to support, absolutely not; take the example of the SD card reader on the D4x0: we all see the card reader in all versions of OS X, yet it's not supported.

Now, get a copy of IORegistryExplorer and post the saved output too.

OOB means out of the box, so yes, just pop it in and you're good to go. At worst, refresh your kext cache.

Check your antenna connections. PS: no double posts please!

No! Don't use any "" characters! These are just a convention to refer to computing terms such as file names! If your DSDT file name is "DSDT.aml" and is placed in folder /Extra, boot using option DSDT=/Extra/DSDT.aml.

Check your default PCI root id. You can check that through a dump of your DSDT table and search for UID attached to device PCI0 or with Terminal command ioreg -l | grep -15 "AppleACPIPCI\ " | grep UID. If you get a non-zero result, then you need to boot with Chameleon option PciRoot=, where UID is the value returned by the ioreg command. I have myself found out that boot option GraphicsEnabler=Yes may not be sufficient to enable full QE/CI for supported cards but that adequate PCI root id was also a pre-requisite. The alternative can be to patch the DSDT so as to convert a non-zero PCI root UID to 0 in order to subsequently boot with default PCI root value of 0. Do try and post us a copy of a clean of IOReg output + extracted DSDT table (i.e. when your system is booted without any DSDT file).

D420 behaves exactly like the D430 in every respect. So password is required to avoid KP at wake but, as reminded by Bronx, if BIOS is configured as per published recommended settings, you'll "only" have to enter system password at cold boot and restart, not on wake.

No particular issues for audio or sleep on those little laptops, so it's just a matter of selecting the right pack in EDP. Just don't use myHack v3.3.1 for Snow Leopard.

You have a 32bit Core Duo U2500 CPU, not a 64bit Core 2 Duo CPU. Lion needs 64bit Core 2 Duo minimum, so you can't actually install it on that D420. You are therefore limited to Snow Leopard unfortunately. See the following old thread on same matter: https://osxlatitude.com/index.php?/topic/1373-lion-on-d420-core-2-duo/ When D420/D430 laptops are fitted with a Core 2 Duo CPU, that is clearly reflected in the BIOS Setup Processor Info page. This is not the case with your model.

It's not something I've noticed as required with all those recent Kozlek's FakeSMC versions, but you may want to edit the CPU Monitoring PlugIn to manually specify your T9500 Tjmax value (105°C) if the system appears to have a problem detecting it and reporting the correct T°.

If you've deleted the nVidia kexts, you no longer have a Vanilla installation and I can't really help you. You should reinstate them, there is simply no way you can get graphics acceleration without nVidia kexts! There's no real improvement to gain in patching the DSDT other than cosmetic information regarding other hardware such as Ethernet, audio or any other hardware that may not be listed. On top of patching for your FX3700, I've also changed PCI root UID to 0 (from 4) so that you don't have to add Chameleon boot option PciRoot=4 at boot time. Try and boot with -f UseKernelCache=No, then re-run myFix (quick) to rebuild permissions & cache. Then reboot. If this is still not giving you LAN & Audio, then change back the .dsl source file: look for Device (PCI0) and change back _UID from 0 to 4.

Really? Seems I was totally wrong on that front then.

Try with GraphicsEnabler=No, in case there's an issue with that model of GPU. I have not looked at the FX1600M myself, but did you check the chip it's built on?

Why not try with the DSDT of the M4300?

Yes, it is, unless you started to modify things like kexts in /S/L/E or other things like that. Copy the patched DSDT to /Extra, then boot using option DSDT=/Extra/ to make sure you load it + GraphicsEnabler=Yes.

Afaik, PC Card/PCMCIA/Express slots of those D Series laptops are unsupported since SL 10.6.7.

.dsl file is source code. the .aml file is the compiled version you use. You don't have to reinstall Mavericks, no, well unless you used some form of distros, something we always discourage to use. We advocate full Vanilla installations and that's all we can support here. "Vanilla" is the term used to designate standard unmodified OS X kexts/kernels/installations. To that, you can oppose patched kexts, patched kernels or distros.

Undo those changes, i.e. get rid of the enabler and only use the Vanilla kexts. Here's your patched and cleaned-up table Deepak: Patched_DSDT_T3400.zip Please note that default PCI root was set to 4 in your extracted DSDT, so you probably would have never obtained full QE/CI unless you booted with option PciRoot=4. This is now changed to default value 0 in the patched DSDT.

Erm.... that's what we were doing!