Hervé

Read this. No emulated SpeedStep please, that's where your problems come from. You're using native SpeedStep now... I assume that when you write: you mean you've removed them from /E/E before doing a myFix (quick), correct?

Ok, it's as I thought: 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) You can grab the required kext off the Vostro200 pack, posted here.

You would normally tick the DropSSDT option if you use your own SSDT tables. If you're using default/built-in BIOS tables, don't tick that.

Try the attached /Extra folder. Minor things could require modification as the DSDT was patched for my WLAN card and Extra/Extensions contains patched kexts for BT and WWAN which you may not have. Won't affect ability to boot and run Lion on your machine though... D430_Extra.zip

You need to tell us what Ethernet card you have in that desktop? Then, we should hopefully be able to point you towards a specific kext. I'd say there's a good chance you'll need the Intel 82566M kext, but we'll see? Assuming you have the lspcidrv kext in /E/E, use Terminal to get your lspci data through command lspci -nn and post us the results.

1) Try and disable IDA (Dynamic Acceleration) in BIOS. We did notice that IDA enabled with Merom CPU caused FSB to run much slower (~10% slower) than the normally expected speed (eg: 726MHz instead of 800MHz) and that had a direct impact on CPU speed of course! It sounds very similar in your case. 2) When you play with FakeSMC and SMBIOS profiles, did you apply different SMC key values to the FakeSMC plist as described in the Performance article? That sure is the best way to try and find the best SpeedStep/PowerManagement setup with native power management.

Ok, will look at it later on today.

@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.