That is a kind of hazy statement isn't it. I've read it three times and still not sure what value it should be.
Well, I'll stick to my statement until someone proves otherwise.
OK Granted I think you're right ... but surely users with unsupported CPU's (like me!) shouldn't be letting SW manage the transition?! and if anything that value should be 0xFE (HW_ALL)!
If I'm right, and our CPUPM kext strictly follows the ACPI Specification, there should be no problems, because we (our ACPI tables) tell OSPM what and how to do, but let's wait for a really experienced guy's reply on this.
[...] So by using 0xFC rather than 0xFD OSPM will treat all cores as 1. Surely you should be using 0XFD?
IMHO it's the exact opposite, and to prove it, take a peek at the Example in the ACPI Spec rev. 4.0 page 329, where it says "[...] OSPM will be required to coordinate the P-state transitions between the two processors and can initiate a transition on either processor to cause both to transition to the common target P-state." and the value in the example code is 0xFD.
You can take my dsdt from Gigabyte thread, on both both my systems it is pretty much only voltages that change until cpu load is about 10 %, then also the multipliers start changing, I'd say that 99 % of time voltages and multipliers change at same time on all cores.
Ok then, I was starting to think that I was torturing my CPU for days... BTW, is there any good explanation for the bold part? It's strange, but does happen with mine too. (How come it doesn't hurt the CPU if it changes voltages for nothing so often?)
I do have all P-states working on OS X, and cores are working independently. It's just that most of the times it's only the lowest and highest steps that are used.
Uh-oh. Something must be wrong at me, can you please upload your DSDT? (My cpu's cores always change states simultaneously, and really often.) Stupid speedstep jumps up and down while just browsing the web (no flash content) with playing music and downloading torrents in the background.