Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Try monitoring the core voltage, core frequency, and memory frequency of the GPU to see if it's really not clocking down, or if the temperatures are staying high for some other reason. I'm not sure if HWSensors displays this info, but using the latest iStatMenus I'm able to see what appears to be correct values for the GPU clocks and voltages being reported by GPUSensors.

Using the latest code from git (c5414419e2), multi-GPU monitoring is working great. Nice job! I'm now able to see the clocks, voltages, and temperatures of both my GeForce GTX 570s. However I noticed that fan speed sensing is gone for both GPUs. Looking through the commit logs I can't see anything that might be specific to this. But could this be related to the fix for multi-GPU monitoring? Back when multi-GPU monitoring wasn't working, fan speeds were the only thing that worked for both GPUs. While all the other GPU sensors only displayed GPU1, fan speeds were shown for both GPU0 and GPU1. How that all the other sensors work for both GPUs, both fan speeds are gone. Any idea which commit might be relevant to this?

I'm aware. But the script in OSInstall.mpkg is calling sysctl, which is then I assume using the CPUID instruction to retrieve the list of CPU features. That's why I think sysctl is tacking VMM to the end of the list of features it retrieves when it detects it's running on a virtual machine, since that feature isn't one that CPUID returns.

Interesting. The "VMM" feature doesn't seem to be a feature that CPUID actually returns. Is this a bogus feature that sysctl tacks onto the end of the real feature list so that other utilities can use it to detect if it's running inside a virtual machine? If so, I guess that means the real virtual machine detection logic is hidden in sysctl somewhere.

Ah, great discovery! Although I offer a different explanation. Geekbench maintains a Mac benchmarks page with all the Mac models listed. It must care about making sure that only real Macs are on those lists (or, failing that, making sure that only self-claimed Macs with the processors that that model is supposed to have is on that list). This presents a problem for computers whose self-identification string exactly matches the model numbers that Geekbench assigns to these Mac models. So their solution: just rename them Hackintosh. For all the machines that do not exactly match the post-translation Mac model names, including those that use the pre-translation Mac model names, like MacPro5,1 etc., Geekbench doesn't care because those model names are not used for the real Macs, due to the way Geekbench translates real Macs' model names into something like "Mac Pro (mid-2010)", so it leaves those model names alone, rather than changing them to Hackintosh.

Hmm...is it possible that while running the Xserve DSDT the CPU power states are not being set correctly? Is there a way to reliably get the CPU multiplier and core utilization while running Geekbench?

Thank you for the very detailed instruction. I didn't know about the role the SMC played in the system interrogation process. That was very helpful.
My next question would be, what values does OS X expect to retrieve from the SMC in order to proceed? I originally thought this would be something as simple as the manufacturer string identifying as "Apple", but VMware's SMC emulation seems to identify the machine as made by VMware with a VMware specific model name. Is the system using something more subtle in order to identify Apple-made hardware and approved hypervisors?

It seems to happen with LGA1155-based systems as well. For example, here's 27-inch iMac (mid 2011) versus iMac12,2
http://browser.prima...inch mid 2011)"
http://browser.prima...odel:"imac12,2"
You can see that the latter list is made up of mostly hackintoshes with non-standard (that is, not one that Apple sells) CPUs.
I suspect that if a real iMac user upgraded his or her CPU to one that Apple doesn't sell, that model will be identified as iMac12,2, and if a hackintosh user has a Core i7 2600 that model will be identified as a 27-inch iMac (mid 2011) as long as the rest of the system identifiers also line up. The latter hypothesis can be verified if one goes through the first list I linked to and see if any systems on there have BIOS strings that may indicate it's a hackintosh. Unfortunately that list is way too long to go through and I don't see any way to filter by BIOS string.
Something else that's interesting is that if you have a real iMac12,2 running Windows, Geekbench will identify it as an "Apple Inc. iMac12,2" (note the addition of "Apple Inc." to the model name used with hackintoshes.)
http://browser.prima...tform:"windows"
In this case, though, the processor specs and system identifiers exactly match real iMac12,2s running OS X. But it could be that Geekbench simply doesn't translate these machines into "27-inch iMac (mid-2011)" simply because they are running Windows.

From what I understand, the OS X installer checks the system identification to see if the machine it is running on is a compatible Apple-made computer before it proceeds, which is why hackintosh bootloaders inject Mac identifiers in order to allow the OS X installer to run. However, I'm not sure about other hypervisors, but virtual machines on VMware products do not identify themselves as Apple products to OS X. Instead they identify as VMware7,1 and the like. Does anyone know why the OS X installer nonetheless proceeds on these VMs? Is OS X hardcoded to accept certain VMware-identified machines the same way it accepts certain Apple machines? Or does OS X have a more general way to identify whether it is being installed on a virtual machine and proceeds in such cases?
Also, does anyone know if the machine identification check is only done during install time, or is it also done on each boot of the system as well?

Thanks for moving this to its own topic. I too was hoping to discuss this some more and felt bad for posting it in the original topic.
I think Geekbench is doing some parsing on the processor specs of the machines. For example they have benchmarks by processor model here:
http://browser.primatelabs.com/processor-benchmarks
But my Core i7 950 doesn't show up in that list, possibly because it's overclocked and not at its original 3.07GHz. I think what Geekbench is doing is restricting the benchmarks that are listed under each processor to only those that exactly match some criteria.
I think it may also be doing something similar for the Mac models. It seems to know the exact models of each of the Macs it keeps track of. For Mac Pro (mid 2010) it knows there's a 4 core, 6 core, 8 core, and 12 core model. So I think it may be matching up the Mac models based not only on the system identifiers but also the processor specs. So a MacPro5,1 with Intel Xeon W3565 is correctly identified as a "Mac Pro (mid 2010) 4 core" while a MacPro5,1 with a Core i7 is identified as a generic "MacPro5,1".
To lend some support to my theory, here's a list of MacPro5,1's with Xeon W3565 that are not being identified as Mac Pro (mid 2010).
http://browser.primatelabs.com/geekbench2/search?q=model%3A%22MacPro5%2C1%22+processor%3A%22Intel+Xeon+W3565%22+platform%3A%22Mac%22
If my theory is correct, these should've been identified as Mac Pro (mid 2010) but they are not. However, I noticed that each of them is running Geekbench 2.1.x, while those being identified as Mac Pro (mid 2010) are running Geekbench 2.3.x-2.4. So my theory could still be correct if somewhere after Geekbench 2.1.x there's been a change that allowed real Macs to be correctly identified with their models and years based on processor specs.

I know they are the same. The point is, Geekbench treats them as two different models. Real Macs are recognized as Mac Pro (mid 2010), hackintoshes are recognized as MacPro5,1.
http://browser.primatelabs.com/geekbench2/search?q=model%3A%22Mac+Pro+%28Mid+2010%29%22
http://browser.primatelabs.com/geekbench2/search?q=model%3A%22MacPro5%2C1%22
By the way, looking at that list of hackintoshes, a great number of them carry the tonymacx86 BIOS identifier. I guess their plan is working.

Hmmm...my smbios matches that of a real mid 2010 Mac Pro, however Geekbench still recognizes it as a "MacPro5,1" rather than a "Mac Pro (mid 2010)". I think in order for Geekbench to recognize the machine as a geniune Mac Pro the specs will have to match too. My computer has a Core i7 rather than a Xeon so that probably rules it out.

I thought I'd share my experience with AGPM. I have a GeForce GTX 570 1.2GB. There are a few things I learned that might help others.
First is that the way AGPM works changed between Lion and ML, at least for cards like the GTX 570 which only has three power states. In Lion, power state 1 is the highest performance state, power state 3 is the lowest performance state, and going between states 1 and 0 does nothing. However, in ML, power state 0 is the highest performance state, power state 2 is the lowest, and going between power states 2 and 3 does nothing. So depending on whether one is using Lion or ML, the modifications needed for cards with fewer than 4 power states is going to be different.
Something else I learned is that AGPM can fail silently, it can issue the command to switch to a power state yet the GPU does nothing. This is most obvious on NVIDIA cards when using two monitors. Until recently, NVIDIA cards are unable to transition to lower power states while using two or more monitors. This was recently fixed with the 300 series of drivers for Windows. Unfortunately, based on my testing, the version 304 driver for OS X available from NVIDIA still does not enable power savings features for my card at least while using two monitors.
Finally, it might be helpful to some to know that adding devices to AGPM can work with a separate plist-only kext. You don't have to modify the AppleGraphicsPowerManagement.kext itself. This is nice in case the kext is updated, in which case your modifications to AGPM.kext may be lost, but if you provide a separate kext it won't be touched. For example, for my GTX 570 I created an NVDAGF100AGPM.kext containing only the below Info.plist file placed on NVDAGF100AGPM.kext/Contents/
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleIdentifier</key>
<string>com.atomatica.NVDAGF100AGPM</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>NVDAGF100AGPM</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>IOKitPersonalities</key>
<dict>
<key>AGPM</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.driver.AGPM</string>
<key>IOClass</key>
<string>AGPMController</string>
<key>IONameMatch</key>
<string>AGPMEnabler</string>
<key>IOProbeScore</key>
<integer>25000</integer>
<key>IOProviderClass</key>
<string>IOPlatformPluginDevice</string>
<key>Machines</key>
<dict>
<key>MacPro5,1</key>
<dict>
<key>Vendor10deDevice1081</key>
<dict>
<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>5</integer>
<key>Threshold_High</key>
<array>
<integer>70</integer>
<integer>85</integer>
<integer>100</integer>
<integer>100</integer>
</array>
<key>Threshold_Low</key>
<array>
<integer>0</integer>
<integer>80</integer>
<integer>95</integer>
<integer>100</integer>
</array>
</dict>
<key>LogControl</key>
<integer>1</integer>
<key>control-id</key>
<integer>18</integer>
</dict>
</dict>
</dict>
</dict>
</dict>
<key>OSBundleRequired</key>
<string>Safe Boot</string>
</dict>
</plist>
All you have to do is add your device id to a separate plist like so, place it in /S/L/E/ and rebuild cache.

I think I may have found a bug. While installing to a new partition with only OS X files and no bootloader or /Extra folder on it, the installer failed to create and write the specified settings to the org.chameleon.Boot.plist file. The logs show that while trying to write those settings, the error encountered was that the file was not found. Seems like the installer just needs to create the /Extra folder and a blank org.chameleon.Boot.plist file if those do not exist yet.