Hervé

@Dan, what we can try and do re: Ethernet controller is add the info in the DSDT as opposed to inject device properties through the boot plist. That's always more elegant if I may use that term. Post us your current IOReg output and your DSDT and I'll see what we can do.

On paper, there should be no problem with your hardware in terms of compatibility. Just follow the process detailed in EDP pages of the site. If there is no OSXL bootpack for your particular model, just use the Generic one offered by myHack.

Check your BIOS and, if required, adjust according to the recommended settings in the dedicated pinned thread on the matter. Disable Wireless if you have an Intel card. If you still have the same problem, rebuild your myHack installer and make sure to apply the OSXL bootpack afterwards (not automatic on myHack v3.3.1 -> Install Extra option in the menu).

You should not need anything special to get full QE/CI on Lion, no Natit or anything like that, just boot 32bit kernel mode (arch=i386), that's all. X3100 is not supported in 64bit mode. You probably need GraphicsEnabler=Yes too.

Probably need to use AppleACPIPlatform kext v1.3.5 instead of vanilla version... Is it a myHack installation? AppleACPIPlatform.kext.zip

GUID is fine. To boot, you need a bootloader such as Chameleon (that's what we recommend) but I don't think that is compatible with UEFI. Can you switch back to legacy at all? If you still have Windows, you can use a tool like Aida64 Engineering to extract your DSDT and various other ACPI tables. Failing that, from Mac OS/OS X, it can be done through tools like DSDTEditor or Chameleon Wizard; this on the condition that you're not already using a DSDT file or it will simply extract that, rendering the task useless!

Thanks to RampageDev & Bronxteck's help, final DSDT patching was made to support Sleep & Wake functionalities, the only outstanding matters that remained on my Precision 670. The cosmetic patch made previously for Device (FRWR) had to be entirely removed (editing Firewire DSDT entry breaks sleep) and the following code added to each USB device (from USB0 to USB3): Method (_DSM, 4, NotSerialized) { Store (Package (0x0B) { "AAPL,clock-id", Buffer (One) { 0x01 }, "device_type", Buffer (0x05) { "USBn" /* where n=0 to 3 */ }, "AAPL,current-available", 0x04B0, "AAPL,current-extra", 0x02BC, "AAPL,current-in-sleep", 0x03E8, Buffer (One) { 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } In addition to the DSDT patch, it turns out that SleepEnabler kext is also required to support sleep. SleepEnabler caused issues in the past when I was experimenting with installation, so it's probably best to add it as a post-install item during fine-tuning phase, not at initial installation phase. With SleepEnabler kext added to /E/E as a last item and installed through myFix (quick), everything now works 100% and without any problems. So, as a final recap: Working: MyHack installation (in my case installation of retail SL 10.6.3 + combo update to 10.6.8) with Nawcom's legacy kernels (tested with 10.3.0-10.8.0 v2) 32 & 64bit kernel modes IDE & SATA controller (with IOATAFamily kext containing ICH5-capable AppleIntelPIIXATA plugin) audio in 32bit kernel mode only (with AppleAudioAC97 kext - may cause KP in 64bit kernel mode) built-in LAN in 32bit kernel mode only (with old PPC/x86 AppleIntel8254XEthernet kext) USB & Firewire full Nocona/Irwindale CPUs detection (2 CPUs, 2 threads if/with 2nd CPU + Hyperthreading are enabled in BIOS) native CPU power management (native speedstep appears supported with Kozlek's recent FakeSMC kext) restart & shutdown (CMOS reset avoided through DSDT Patch or usual RTC fix kexts) sleep & wake (with DSDT patch & SleepEnabler kext) Full QE/CI graphics acceleration with the right graphics card and all eventual kext + DSDT patches (for instance: ATI Radeon Pro X1300/X1550, nVidia GeForce G210, nVidia GeForce 9800GT) Not working: AC97 audio in 64bit kernel mode -> corrupted audio unsupported built-in Adaptec AIC-7901 Ultra320 SCSI adapter Below are the revised packs, IOReg output and extracted/patched DSDT tables: Precision670_revised_packs.zip WS670_IOReg(v2.0b1).ioreg.zip Precision670_DSDT.zip

Why do you delete myHack kext from /S/L/E to follow that myFix (full) when you want to rebuild your cache?

-> PM

When Mavericks 10.9 was released, Double Command turned out incompatible and would cause the system to crash. This was fixed back in late October and a new release was published. Mavericks now fully supports that nice little keyboard remapping tool as of version v1.7. Highly recommended! http://doublecommand.sourceforge.net

D630 issues/matters are to be discussed in the appropriate section please.

It depends on the version of FakeSMC. It's not required with recent Kozlek's version since 5.x.yyy as the FakeSMC kext uses a specific CPUSensor PlugIn that renders IntelCPUMonitor obsolete. It can also clash with FakeSMC. It's best to use a recent FakeSMC kext and get rid of that old IntelCPUMonitor kext.

Of course you need /Extra! myHack takes its PlugIns from there. If you remove kexts from extra, they'll be totally removed from myHack's PlugIns folder after a myfix and will no longer be available at all. myHack takes kexts from /Extra/extensions, bumps up version to 1111 and copies then to the PlugIns folder of /S/L/E/myHack.kext. This is how they can get loaded at boot time. If the kexts were only on /E/E, they would not be loaded. That clever mechanism allows to use a kext of a same name as a Vanilla kext in /S/L/E but supersede it through version bumping: OS X always uses kexts with the highest version if in presence of multiple kexts of the same name. This basically allows to leave /S/L/E completely unmodified and totally Vanilla, so users control things a lot more without risks of overwriting a vanilla kext if it's ever required to roll back.

The need to set PCI root to 4 can be avoided by patching the DSDT so that PCI root is set to 0 by default. This is done by changing PCI0 _UID from 4 to 0 as shown below. -> Before: Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_UID, 0x04) /* old default UID */ Name (_ADR, Zero) -> After: Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_UID, Zero) /* new modified UID */ Name (_ADR, Zero) System can then be used with default PCI root UID (0) without any adverse effects.

Were both IOReg & DSDT extracted from a OS X boot without specific DSDT.aml file or from Windows? I'm seeing a mismatch between the two, so this needs clarification.

To patch the DSDT, we would need you to boot OS X without one (I mean without a DSDT.aml file) and post us your IOReg + clean extracted DSDT.

Are you still booting with PciRoot=4? Is it 1st or 2nd DSDT (2nd one is without errors/warnings correction, just basic GeForce injection)?

Feel free to remove the verbose flag if you so wishes, but it's a general rule that our bootpacks contain it.

Ok, it was just in case you had a DW350 which used to be known for disturbing audio after a while.

Seems no specific kext is required... http://www.insanelymac.com/forum/topic/261782-100-working-ati-mobility-radeon-hd-5470/

Install EDP, do the system build for your model and make sure to select VoodooHDA audio if it's not selected by default. Do you have any Bluetooth module by any chance and if so, which model?

Can you not do an lspci -nn command under your Ubuntu live disk? That would be so much simpler and clearer as this is still not ideal... Anyway, 1st thing 1st: you have an Atom kernel so you can only boot with an Atom-specific patched kernel... Mach kernel won't do. Secondly, I think this Tosh' has GMA 3150 integrated graphics, which is totally unsupported by Mac OS X. Should this graphics chip be confirmed, I'm afraid you can forget about turning this into a Hackintosh as it would never run properly. Sorry...

Try without cache too: PciRoot=4 -f UseKernelCache=No GraphicsEnabler=Yes -v. I'm really surprised it does not work when you can boot Ok with no DSDT and I had an identical situation on my Precision 670. I suppose you could always create a new partition on your HDD and attempt a new installation on it. Make sure you use my 2nd patched DSDT from the onset, i.e. add it to your myHack installer bootpack and always make sure to boot either with your tuned boot plist or with options PciRoot=4 GraphicsEnabler=Yes.

Try this new one: dsdt_xps420.aml.zip

Was PCI Root still at 4? It's normally visible from the very 1st lines Chameleon boot lines at the top of the screen and quite visible when LAN and Graphics card are detected by the bootloader.