Hervé

Are you using NullCPUPowerManagement kext? It's probably required for that system. You may need a legacy/AMD kernel like Nawcom's, rather than the vanilla version. There were Atom patched kernels too, but not applicable in your case.

Could be useful to specify initial + updated version of FakeSMC you used.

For Sleep & Wake to work on the D430, you need: System password set in BIOS No use of SleepEnabler or NullCPUPowerManagement kext (to be removed from /E/E or /S/L/E if found there) PStates + CStates generation enabled in the Chameleon boot plist Hibernation configured for good old sleep to RAM (use Terminal command sudo pmset hibernatemode 0) No sleepimage file in /var/vm (if file exists, delete it with Terminal command sudo rm -f /var/vm/sleepimage) Check your current (and future) hibernation mode with Terminal command sudo pmset -g. Did you read these pinned threads? https://osxlatitude.com/index.php?/topic/2848-native-speedstep-sleepwake-on-core2duo-d430/ https://osxlatitude.com/index.php?/topic/2036-bios-settings-d430/

Please consult our wireless card inventory. JakeLo linked to it in his signature.

Like JakeLo said: There are no known OS X drivers for that model on Mediatek web site -> replace it by a supported card (watch the damn HP whitelist!) or use a supported USB dongle.

This performance tuning can now be further improved with AGPM tuning in order to achieve best possible GPU performance. Experimentation was made with the D630 nVidia but the same principles should naturally also apply to nVidia-fitted D830/M2300/M4300 or other systems. Initial posts also updated with Sleep/Wake info.

If you have a myHack installation, open up Terminal, run the lspci -nn command then post the results here. This will list the complete set of hardware connected to the PCI bus. We'll then know exactly what kind of LAN interface you have and that'll help us identify the likely driver for it.

Much has been written about GPU tuning with AppleGraphicsPowerManagement (AGPM). There are good threads on the matter at InsanelyMac and Olarila or on RampageDev's blog and many other places that I simply cannot list exhaustively. http://olarila.com/forum/viewtopic.php?f=18&t=1839 http://www.rampagedev.com/?page_id=311 A couple of years ago I did some research with Bronxteck on the matter of CPU/GPU performance tuning with FakeSMC. Whilst we achieved good results, I noticed ages ago that my D630 nVidia had no GPU throttling after waking from sleep and GPU remained on high speed leading to very high T°. As my motherboard recently failed again due the well-known nVidia GPU weakness and got revived through "baking", I decided to look in to the matter to avoid unnecessary GPU fast clocking and consequential lengthy overheating. I sought to fix the issue with AGPM. Here are my findings... Recap of the D630 GPU-related specs & configuration: nVidia Quadro NVS 135M GPU (based on GeForce 8400M GS (G86M) chip). GPU PCI ven/dev ids: 10de/042b (in hex) 3 known GPU PStates (=power states: GPU Core/RAM speed): 168/100MHz, 275/300MHz, 400/594MHz SMBIOS used: MacBookPro5,1 In order for graphics power management to work as expected, the Info plist of the AGPM kext must normally have an entry for the targeted Mac model and targeted GPU. The plist does have an entry for the MacBooPro5,1 and a quick look at it shows: <key>MacBookPro5,1</key> <dict> <key>GFX0</key> <dict> <key>BoostPState</key> <array> <integer>0</integer> <integer>1</integer> <integer>2</integer> <integer>3</integer> </array> <key>BoostTime</key> <array> <integer>3</integer> <integer>3</integer> <integer>3</integer> <integer>3</integer> </array> <key>Heuristic</key> <dict> <key>ID</key> <integer>0</integer> <key>IdleInterval</key> <integer>250</integer> <key>SensorOption</key> <integer>1</integer> <key>SensorSampleRate</key> <integer>4</integer> <key>TargetCount</key> <integer>1</integer> <key>Threshold_High</key> <array> <integer>57</integer> <integer>65</integer> <integer>82</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>68</integer> <integer>75</integer> <integer>95</integer> </array> </dict> <key>control-id</key> <integer>17</integer> </dict> <key>IGPU</key> <dict> <key>BoostPState</key> <array> <integer>0</integer> <integer>1</integer> <integer>2</integer> <integer>3</integer> </array> <key>BoostTime</key> <array> <integer>3</integer> <integer>3</integer> <integer>3</integer> <integer>3</integer> </array> <key>Heuristic</key> <dict> <key>ID</key> <integer>1</integer> <key>IdleInterval</key> <integer>100</integer> <key>Threshold_High</key> <array> <integer>50</integer> <integer>75</integer> <integer>96</integer> <integer>100</integer> </array> <key>Threshold_High_v</key> <array> <integer>70</integer> <integer>85</integer> <integer>94</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>40</integer> <integer>55</integer> <integer>92</integer> </array> <key>Threshold_Low_v</key> <array> <integer>0</integer> <integer>50</integer> <integer>60</integer> <integer>92</integer> </array> </dict> <key>control-id</key> <integer>16</integer> </dict> <key>LogControl</key> <integer>0</integer> </dict> Amongst others, Olarila forum + RampageDev's blog provide detailed information on the meaning of the above code. I'll just highlight the fact that the values under the "Threshold..." lines are GPU idle state % (not load %) of P (=power) states 0, 1, 2 and 3 respectively. PState 0 is lowest idle/highest load and PState 3 is highest idle/lowest load. The available literature on AGPM also explains that, in order to obtain good GPU throttling, the AGPM kext should have an entry matching the device listed in the DSDT or corresponding to the computer hardware in the form "VendorDevice". In the case of the MacBookPro5,1 section of the Info plist, we can see an entry for GFX0 and for IGPU. GFX0 is usually for discrete/add-on GPUs (e.g.: nVidia or AMD graphics) whilst IGPU is for integrated GPUs (e.g.: Intel GMA, Intel HD graphics) If we look at the "regular" DSDT for the D630n, we clearly see that the GPU is described under a device called VID. No sign of a GFX0 or a IGPU device. I was therefore a little surprised that GPU throttling actually worked natively, even if only under certain conditions. I did 2 separate things to try and fix the loss of GPU throttling after wake: rename the VID device to GFX0 in the DSDT keep the DSDT untouched and add a Vendor10deDevice042b entry in the MacBookPro5,1 section of the AGPM kext Info plist I also changed the LogControl parameter of the MBP5,1 section of the Info plist to 1 to be able to track GPU state changes in the kernel log. In both cases, results were disappointing: whilst I regained GPU throttling after wake, I could only see 2 GPU states: 275/300MHz and 400/594MHz. No sign of the lowest state 100/168MHz. I tried to tune the various idle % levels specified in the GFX0 entry, unfortunately to no avail... Mar 14 20:14:21 D630n kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff800b28d800 Mar 14 20:14:21 D630n kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... Mar 14 20:14:21 D630n kernel[0]: AGPM: GPU = GFX0 G-state set to 1 from 0, ControlID = 17. SW occupancy updated. Browsing through the rest of the Info plist, I noticed several nVidia device entries which all had a very specific parameter that differed from the GFX0 or IGPU entries: control-id. In the case of the GFX0 entry of the MBP5,1 Info plist, the parameter holds a value of 17, for IGPU a value of 16 and for some nVidia devices, a value of 18. I therefore thought I'd try to change the GFX0 control-id value from 17 to 18. On reboot, bingo!, HWMonitor app displayed all 3 x GPU PStates. The kernel log entries also showed GFX0 power states varying between 0 (high), 1 (medium) and 2 (low) as GPU load varied. Applying the same value to the Vendor10deDevice042b alternative configuration produced the exact same result. As desired, AGPM now worked after waking the laptop, so the days of the nVidia GPU stuck on highest speed after sleep are effectively gone. Mar 14 21:24:42 D630n kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff800b28d800 Mar 14 21:24:42 D630n kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... Mar 14 21:24:42 D630n kernel[0]: AGPM: GPU = VID G-state set to 1 from 0, ControlID = 18. SW occupancy updated. Mar 14 21:24:23 D630n kernel[0]: AGPM: updateGPUHwPstate(2, 0): fHwPstate = 1 fFB = 0xffffff800b28d800 Mar 14 21:24:23 D630n kernel[0]: AGPM: updateGPUHwPstate(): state = 2. Calling fFB->setAggressiveness()... Mar 14 21:24:23 D630n kernel[0]: AGPM: GPU = VID G-state set to 2 from 1, ControlID = 18. SW occupancy updated. So there we are, GPU throttling at all times on the D630 nVidia using one of the following 2 solutions: Rename the correct VID device to GFX0 in the DSDT + change the control-id of MBP5,1 GFX0 entry of AGPM kext Info plist to 18. Be careful here as there are 2 different VID devices in the DSDT: one under AGP device and one under PCI0 device. Only rename the VID device under AGP, then replace all references to AGP.VID by AGP.GFX0. Keep DSDT as is and clone the GFX0 section of the MBP5,1 entry of AGPM kext Info plist to a new Vendor10deDevice042b entry with control-id set to 18. Obviously, solution #2 is the preferred method as it does not require the somehow risky DSDT patch and it fits in line with existing entries in the AGPM kext Info plist. It is also more identifiable due to the clear Vendor/Device section: <key>MacBookPro5,1</key> <dict> <key>Vendor10deDevice042b</key> <dict> <key>BoostPState</key> <array> <integer>0</integer> <integer>1</integer> <integer>2</integer> <integer>3</integer> </array> <key>BoostTime</key> <array> <integer>3</integer> <integer>3</integer> <integer>3</integer> <integer>3</integer> </array> <key>Heuristic</key> <dict> <key>ID</key> <integer>0</integer> <key>IdleInterval</key> <integer>250</integer> <key>SensorOption</key> <integer>1</integer> <key>SensorSampleRate</key> <integer>4</integer> <key>TargetCount</key> <integer>1</integer> <key>Threshold_High</key> <array> <integer>37</integer> <integer>45</integer> <integer>54</integer> <integer>80</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>40</integer> <integer>60</integer> <integer>75</integer> </array> </dict> <key>control-id</key> <integer>18</integer> </dict> <key>LogControl</key> <integer>0</integer> </dict> The idle % levels can be adjusted if/as desired/required (as in above example) to optimise performance. This GPU throttling was experimented and verified under Mountain Lion 10.8.5, Mavericks 10.9.5 and Yosemite 10.10.3. The same principles are of course re-usable for other machines. The patched AGPM kext must remain in /S/L/E. It will be ineffective if placed in /E/E for handling by MyHack...

You don't use EDP on a ModUSB installation; EDP relies on myHack, so unless you've installed it you should not use EDP. Run the combo update and reinstall any kexts you've used during your initial installation + repair permissions + rebuild cache before you reboot.

Erm, I don't know but you did install VoodooPstate intially. Did you re-install the OS?

Sorry, got tied up on my Yosemite builds... Here goes; unzip and try each file individually, though they're all normally pretty identical. Patched-DSDT_set.zip

Most useful on Yosemite... 'love it! One of those little apps that well deserves a donation. Works even on AMD kernels. http://sourceforge.net/projects/cdock/

And up to Yosemite 10.10.2 using that same rc7 kernel from Bronya. Apple have not published the source code of 10.10.2 kernel (Darwin 14.1.0) yet, so we're still on 10.10/10.10.1 AMD kernel (Darwin 14.0.0). I updated through AppStore, then manually replaced the vanilla kernel and rebuild cache from Mavericks to be able to reboot into 10.10.2. Everything appears to work perfectly. NB: Apple Security Update 2015-002 reinstates the vanilla kernel; the kernel replacement process (including cache rebuild) must therefore be repeated after this update.

No, we'll work it out without the need to use EDP.

And he's done it again for Yosemite! I'm still running 10.10.1 and my above screenshots must have been noticed as slightly corrupt... That's because I was running Bronya's 10.10 rc2.1 with which there were graphics glitches and screenshots + editing in Preview was not 100% operational. With Bronya's latest 14.0.0 rc7 kernel, all those graphics defects are fixed. Attached pictures speak for themselves, they're a true illustration of what I get on screen. Bronya_10.10-10.10.1_rc7_kernel.zip

Try the links listed in this old post. Can't verify from where I am right now. If they're dead (I'm not sure Nawcom's blog still exists), I'll upload copies of the ModCD and ModUSB. This being said and as suggested earlier in the other thread, you should be able to install SL with myHack v3.1.2 and its generic bootpack.

Sure, I'll post the other patches to try one by one later on tonight.

I'll see tonight if I have a copy somewhere at home. Meantime, you safely use myHack's generic bootpack.

Bronya released a new rc4 version of his 10.9.5 AMD kernel. It works perfectly on the Precision 670. The little graphics corruption of desktop filenames is gone, taking screenshots works perfectly and editing screenshots in Preview no longer corrupts picture or screws up colours. Also installed latest Security Update 2015-002 which, again, reinstates vanilla kernel so replacement by Bronya's 10.9.5 version is required before reboot. Overall performance is excellent and system very responsive; no lag at all. To me, the man is nearing perfection! Bronya_10.9.5_rc4_kernel.zip

I decided to try and return various alternative values from the _DSM method of the generated SSDT. By trial and error, I regained x17 CPU multiplier and retained Sleep through Fn-F1 when returning a value of 7. I'm therefore sticking to the following code: Method (_DSM, 4, NotSerialized) { Store ("Method CPU0._DSM Called", Debug) If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x07 // This values retains x17 CPU multiplier + Sleep via Fn-F1 }) } Return (Package (0x02) { "plugin-type", One }) } I've also noticed that the Chameleon option DropSSDT=Yes is not necessary to obtain native CPU SpeedStep and/or Turbo boost. I've therefore changed my boot plist to that effect. ssdt.aml.zip org.chameleon.Boot.plist.zip In order to guarantee good behaviour of Fn-F1, make sure hibernate mode is set to 0 and that there is no 'sleepimage' file in /var/vm directory. If present, it must be deleted. A safety alternative consists of pointing the hibernate file to /dev/null. NB: The above applies to both Mavericks and Yosemite. Updated Mavericks pack loaded to post #1 (pack #7) and updated Yosemite pack loaded to post #15 (pack #3).

What kind of patch are you looking for? What's missing or not working or not to your liking? Post the zipped DSDT file.

There are only single instances of patched kernels. Once patched, the kernel applies to all installations or installers. If your myHack installer still does not boot the patched kernel, then it's because something else is wrong with your installation media. You can get the 10.9 Haswell-patched kernels on the Net or on this site. It just depends on the particular version of Mavericks you're using. Look here for instance. They're also available in the download area of InsanelyMac. Yoiu just have to search a little... Then, it's a simple matter of replacing the vanilla mach_kernel file found at the root of the bootable media (USB key or HDD) and re-running myHack->myFix (quick) to rebuild the cache with the patched kernel.

The fan will work as and when required according to CPU and (especially) GPU T°. The nVidia GPU tends to run very hot on these laptops, so you can expect the fan to run high when running a GPU-hungry app; watching a you tube video for instance... We'll work out the D430 in parallel...

'sounds like a Haswell-related reset. If confirmed, use the Haswell-patched kernel and you'll be able to boot the installer.

That would explain absence of module detection! @31337swv: look at the labels on your card to identify the exact model and then look it up on the Wikidevi web site. The link is provided here. What made you think your card had Bluetooth too?