Hervé

Mavericks is fully supported on nVidia models only. Just refer to the compatibility chart. There are no specific issues or bugs. You need to proceed with brand new installation using the usual process and you can install over your existing ML setup to keep your existing files and apps. Mavericks will run just as well as ML 10.8.5 on that laptop.

It's not a compatibility issue with the D620, the issue you encountered is a bug with myHack 3.3.1 for SnowLeopard installers. I've been able to confirm that myself, especially if using it from an existing SL installation (it actually overwrote the installation it was run from). There is no known issue with myHack v3.3.1 for Lion/ML/Mavericks on any machine we support here. If you want to install SL on your D620, try and use and older version of myHack such as v3.1.2.

It's totally stable, have you read anywhere that it wasn't? As far as performance is concerned, I would personally say that it's better with SL than Lion. SL is ever so snappy, quicker to boot and it's a blast to shut down! Make a backup beforehand, but you can normally install a new OS X version over an existing one and it keeps all your files and apps. It certainly worked for me on my D630n when I installed ML over Lion, then Mav over ML. You could always try out Lion from a USB key or an external USB HDD before you make a final decision...

No problem to install & run 10.9.1.

You need a retail copy of Snow Leopard DVD and there are only 3 such versions: 10.6.0, 10.6.3 and 10.6.8. Once you have that, installation is a piece of cake. To purchase a copy of SL 10.6.8, look here. Failing that, Google is your friend...

I made some additional DSDT edits for the (unsupported) built-in Adaptec SCSI controller + AC'97 audio. . For Adaptec Ultra-320 adapter, within PCI2, I added: Device (SCSI) { Name (_ADR, 0x000E0000) Method (_DSM, 4, NotSerialized) { Store (Package (0x0C) { "AAPL,slot-name", Buffer (0x09) { "Internal" }, "class-code", Buffer (0x04) { 0x00, 0x04, 0x01, 0x00 }, "model", Buffer (0x2A) { "Adaptec AIC-7901 Ultra320 SCSI Controller" }, "name", Buffer (0x15) { "RAID SCSI Controller" }, "device-id", Buffer (0x04) { 0x8F, 0x80, 0x00, 0x00 }, "vendor-id", Buffer (0x04) { 0x05, 0x90, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } . For AC'97 audio, within PCI0, I added: Device (HDEF) { Name (_ADR, 0x001F0005) Method (_DSM, 4, NotSerialized) { Store (Package (0x10) { "AAPL,slot-name", Buffer (0x09) { "Internal" }, "class-code", Buffer (0x04) { 0x00, 0x01, 0x04, 0x00 }, "codec-id", Buffer (0x04) { 0x74, 0x53, 0x44, 0x41 /* ADS74 */ }, "built-in", Buffer (One) { 0x00 }, "name", Buffer (0x11) { "Audio Controller" }, "model", Buffer (0x21) { "AC'97 (AD1981B) Audio Controller" }, "device-id", Buffer (0x04) { 0xd5, 0x24, 0x00, 0x00 }, "vendor-id", Buffer (0x04) { 0x86, 0x80, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } This is all cosmetic, but I like it...

It can also help to remove the NVRAM plist from /Extra (if you use the NVRAM module). The file is automatically recreated afterwards.

Well, you don't have any graphics kext loaded for your card, so no graphics acceleration, hence no graphics support. Look no further, that's where you problem comes from. You probably need to patch your DSDT to inject your card details or patch your nVidia kext. Look at RampageDev's blog, I believe he has a post about some GTX card. Of course, you can also head over to nVidia's web site for a driver (maybe a Cuda driver); most people don't even think about that!!!

No problem with 10.9.1, I updated my initial 10.9 installation and had no subsequent problem. Maybe you should just reinstall Mavericks...

I would just add a new entry as opposed to change an existing one. Then set your new vendor id to 16700 (= 0x413c) otherwise you'll never match your actual hardware. No guarantee that this will work though... Only if that W350 model uses compatible firmware as F5321 (i.e. uses the same commands). Your DeviceVendor info should be set to "Sony Ericsson" or "Generic", not "Ercisson" (or "Ericsson"). Basically, this info should match one of the entries in the list of Vendors available in the "Advanced" tab when you configure a WWAN module in the Network Preferences panel. Remember to place your modified CellPhoneHelper kext to /E/E and run myFix (quick) to make it supersede the vanilla kext in /S/L/E.

If you run ML, you should have no problem running Mavericks. You just need to select the correct SMBIOS profile (Mac model) so that you pretend to have a compatible Mac. Use Chameleon Wizard to that effect.

Well, this is handled by BIOS, so maybe a DSDT patch could disable it but I would not bet any money on it...

The DW5560 appears to be based on Ericsson F5321 chip; as such, you should try to base your CellPhoneHelper kext patch on an Ericsson profile, not a Novatel one.

Nope.

Well, running any given OS X version can never be taken for granted; that's one of the most basic rules with Hackintoshing. If you were able to install Lion, maybe you should stick to that version.

Dis you disable the nVidia in your BIOS? Optimus is not compatible with Hackintoshes, so you probably need to stick to Intel graphics, unless you can opt for the GT620 only.

Do you see the card in System Report at all? Under USB section?

Can you please open up a Terminal window and type lspci -nn to list your detected hardware and post the results here? This will show us what you have but as JakeLo mentioned, probably an Intel card.

If you intend to use the OSXL bootpack, then you should not choose "Generic" Extra at the end of your installation but "my own", pointing to the OSXL bootpack that you have used on your USB installer (using the same process, i.e. Install Extra->my own-> point to downloaded Zenbook boot pack) and which will be in /Extra of your USB installer. Right now, it appears that you boot your installer with the boot pack but complete your OS X installation with the Generic boot pack! That kind of defeats the purpose of a dedicated bootpack for your model... What you can do meantime is reboot your USB installer and once at installation screen, go to Tools menu, select myHack and opt for "Install Extra" and "my own". Choose your HDD OS X partition as destination and use the /Extra of your USB installer as your source location for the bootpack. This will basically install the Zenbook boot pack on your OS X installation, something you seem to have missed previously.

Well, the problem seems to be that you don't have the correct SSDT for your particular CPU...

You probably need a DSDT patch so that the card is recognised properly and with all its characteristics. I would suggest you use IORegistryExplorer to find out the various details for the card (PCI location, nVidia characteristics, etc.) then extract a clean DSDT table so that we try and patch it. If you manage to boot without any DSDT table, you can use Chameleon Wizard or DSDTEditor to extract it and then decompile it to obtain the dsl source code. Don't hesitate to save your IORegistryExplorer output to file and upload it here together with your DSDT table. I would also recommend that you check your default PCI root level using command ioreg -l | grep -15 "AppleACPIPCI\" | grep UID from a Terminal window. Add your lspci -nn output too.

You need to remove that offending DisableTurboBoostBattery kext from wherever it is (/S/L/E or /E/E) then re-run myfix (quick).

I've been playing with DSDT patching these last few days and decided to try and get rid of the NVenabler64 graphics enabler kext used for the nVidia 9800 GT; that meant a DSDT patch of course. I first extracted the DSDT through Chameleon Wizard since I was not using any patched one. Then, I checked PCI devices in IORegistryExplorer and found the nVidia card to be located at PCI5@4, under PCI3. I therefore patched the DSDT as follows: . under _WAK method, I added: Method (DTGP, 5, NotSerialized) { If (LEqual (Arg0, Buffer (0x10) { /* 0000 */ 0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, /* 0008 */ 0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B })) { If (LEqual (Arg1, One)) { If (LEqual (Arg2, Zero)) { Store (Buffer (One) { 0x03 }, Arg4) Return (One) } If (LEqual (Arg2, One)) { Return (One) } } } Store (Buffer (One) { 0x00 }, Arg4) Return (Zero) } . within PCI5 device, under Method (_ADR, 0, NotSerialized) { [...] Store (0x00040000, Local0) [...] } section, using info from the IORegistry extract, I added: Device (GFX0) { Name (_ADR, Zero) Method (_DSM, 4, NotSerialized) { Store (Package (0x1A) { "AAPL,slot-name", "PCIe x16", "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,connector-type", Buffer (0x04) { 0x00, 0x08, 0x00, 0x00 }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "VRAM,totalsize", Buffer (0x04) { 0x00, 0x00, 0x00, 0x20 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x17) { "nVidia GeForce 9800 GT" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Note that most of this derives from RampageDev's excellent blog page on graphics cards DSDT injection. Thank you Andrew! After removing the enabler kext and re-running myFix (quick), I rebooted but system remained without QE/CI, as if graphics card DSDT injection was ineffective. On checking the IOreg a little deeper, I found the system to have a PCI root level I was not expecting... Mac-Pro:~ admin$ ioreg -l | grep -15 "AppleACPIPCI\ " | grep UID Result --> | | | "_UID" = "4" Rebooting with boot option PciRoot=4 subsequently resolved the graphics card DSDT injection issue and got me full QE/CI! The Chameleon boot plist was therefore amended to that effect. Whilst on the Precision 670, I also searched deeper into the Ethernet port issue (seen and recognized, but always down with "Cable disconnected"). I finally found an old universal 32bit (PPC & i386) AppleIntel8254XEthernet kext on the Net and it proved to fix the issue! Yeeha! That old kext is v1.1.2 and possibly from Tiger but that's not important. It made the LAN port work, that's important! I also patched the DSDT to be able to show the Ethernet port + Firewire in the System Profiler->PCI cards section by adding the following sections derived from an IOReg scan. .For Intel Pro/1000MT NIC, within PCI3 device, I added: Device (LAN0) { Name (_ADR, 0x000E0000) Method (_DSM, 4, NotSerialized) { Store (Package (0x0C) { "AAPL,slot-name", Buffer (0x09) { "Internal" }, "class-code", Buffer (0x04) { 0x00, 0x00, 0x02, 0x00 }, "name", Buffer (0x17) { "10/100/1000BT Ethernet" }, "model", Buffer (0x1A) { "Intel Pro/1000MT Ethernet" }, "device-id", Buffer (0x04) { 0x26, 0x10, 0x00, 0x00 }, "vendor-id", Buffer (0x04) { 0x86, 0x80, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } . For Firewire, within PCI6 device, I added: Bad idea - all removed! --------- EDIT - 15Jan2014: Modifying DSDT code for Firewire is actually a very bad idea because, as stated by RampageDev, it breaks Sleep! As such, Firewire patch was totally removed.

Yes I'm 200% sure of the code, I use it in my D630n DSDT. Make sure you copy paste it properly and, if you use TextEdit, that option Smart Quotes is not ticked in menu Edit->Substitutions. That tends to mess up DSDT source code and cause compilation errors if set...

Just do a search on the applications names, you should find them if they're on disk. You can also check they're all valid by launching them...