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.
[...] Please note that we went on removing this because I don't need this (neither did mm67) though your board seems to need it. [...]
Hmm... Unfortunately power still doesn't go off when going to S5. As I've been reading some info in the ACPI spec and the ICH9 datasheet I've found that _PRW and _PSW are responsible per device for choosing the correct device state depending on global state. It looks like that OS X thinks USB devices should wake up the sleeping (S5) system, therefore it doesn't cut power and leaves the USB in D2 (or D1? and it stays like this till the next power on's USB re-init by the BIOS), even if the corresponding function in the BIOS is off. It should be the USBW's value that does this, shouldn't it? P.S: I have the Wake for Ethernet network access option turned off in Energy Saver, does that really wake the PC occasionally, and can it make a difference in this kind of problem?
As I see there shouldn't be anything that does anything like this. (SCP is about thermal policy and SMIP is about the SMBus controller's interrupt pin.) So are there any users whose keyboards/mice LEDs light up as they press a key after the computer has been shut down by Snow Leo? (Negatives are important too, so please, report, but in a non-polluting way, so make your posts have something else in them.)
@ FormerlyKnownAs: You've been trying dropssdt=no and enabling c-states + EIST in your bios while your model was MacPro3,1 right? Then if that's the case, the only (maybe) relevant differences in our DSDTs are the PNOT method and the defined PDCns, nothing else (except the defined frequencies and power). You may need a wizard to help you, because it really should work. (BTW, how was it working earlier?)