DSDT - Vanilla Speedstep - Generic Scope (_PR)

[waldo_pepperjack]

...

 

1. With my board I only use FakeSMC, LegacyHDA and IOBlockStorage kexts (bonjour is via ifconfig).

 

Check out my dsdt, its pretty well annotated with the fixes etc, compare it to yours, wake via apple usb keyboard has also been fixed.

 

2. I'm still tinkering with my pstates and they are for a Q9550.

 

Credit goes to mm67 for his excellent work.

 

 

EDIT:

3. Your link to your dsdt appears to be broken

1. Yup, that's what I'm shooting for as well.

 

2. Here are my current p-states that I'm using:

waldo's p-states 1-09-2010 for Q9550 OC'ed to 3.4GHz on a GA-EP45-UD3L

 

3. Sorry about that, Keeza. I took it down as I now see that somewhere along the way I used a dsdt.dsl that I __didn't__ want to ... to be honest, now looking at the one I had posted, I am sure that this is not the one that has some of my important edits in it. I'll repost it once I finish updating the __correct__ one. If mm67 hadn't have notice that, I might have never suspected it.

 

I knew I'd done the built-in EHCI fix ... and I've found the correct old dsdt.dsl that I'd done that edit to. So now it is just a matter of me putting in the proper P-states & I should be where I want to be.

 

Makes me wonder if I need to install git or subversion on one of my local NAS devices so I can keep this all straight.

 

Time for some fixxy-fixxy!

[keeza]

I knew I'd done the built-in EHCI fix ... and I've found the correct old dsdt.dsl that I'd done that edit to. So now it is just a matter of me putting in the proper P-states & I should be where I want to be.

 

I know the feeling there, I think I have 7 folders with different dsdt's in them!!!

 

So I noticed your VID varies significantly to mine, is that a result of your OC? What value have you vcore set it BIOS?

[waldo_pepperjack]

Your link to your dsdt appears to be broken

 

OK, all done ... I put a link here in a better thread for this...

[kt6uk]

thanks to this forum and the experts who help out I have 10.6.2 vanilla install working on a GA-P35-DS3L E5200 power MB with a patched DSDT (manually by me).

All works well apart from speed stepping which I'm trying to fix up.

 

I'm wondering if its possible to re-use someone elses entry for an E5200 into my patched dsdt ?

 

In the mean time I'll try and extract the actual p states from my rig - but having trouble finding an app which works :-( pstatechanger crashes on me !

[kt6uk]

So close to getting speedstep working. Worked fine with voodoopstate, but really want it in my patched DSDT :-)

 

Here's hoping one of you experts can help a newbee :-)

 

I've followed the instructions and created three entries for the P states and have checked in ioreg that AppleLPC exists - it does with an ID of 026a or 0244 (seems to vary???) , there's also LPCB@1F just above it ID if 0156, but there's nothing in the AppleLPC.kext plist which comes close.

 

Output from ioreg:

 

| | +-o LPCB@1F <class IOPCIDevice, id 0x100000156, registered, matched, active, busy 0 (13815 ms), retain 18>

| | | +-o AppleLPC <class AppleLPC, id 0x100000244, registered, matched, active, busy 0 (5 ms), retain 5>

 

Below is my LPCB entry fro my dsdt as it stands with 2916 as the ID which matches one in the plist.

 

Should I just change the below dsdt entry to 6a20 so it matches the ioreg dump ?

 

 

Device (LPCB)

{

Name (_ADR, 0x001F0000)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"device-id",

Buffer (0x04)

{

0x16, 0x29, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

 

Interestingly when voodoopstate was installed I could see the clock rate changing between 1200 at idle and 2500MHz under heavy load with 13 pstates and the power being consumed rising from 132 watts to 154 watts as measured on my 'kill a watt meter'.

 

Now with voodoopstate remved and my attempt at speed stepping, at idle the power is 128 watts and 148 under identical heavy load but CPU-x now always reports 2500MHz rather than ramping up then down as it did before - so maybe it is working despite the LPCB issue above and CPU-x is just wrong ???

 

EDIT

 

So I just found and installed cpu-i and watching its output, the clock freq is switching ok between the max 2500, 1800 and min 1200MHz pstates I entered - so I guess its working and CPU-X is incorrect when used without voodoopstate changer ????

 

I'll upload the fully patched dsdt later when I'm sure it's ok.

[westwaerts]

for monitoring the DSDT Speedsteps i found an app called "mark-i" , which is russian only, but you´ll understand.

 

@kt6uk

you need lspci info of you machine ( not the os)

where you get listed the devices ( here from my machine)

 

00:1f.0 ISA bridge [0601]: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller [8086:2810] (rev 02)

 

if AppleLPC is not loaded, the 8086:2810 is not listed in the info.plist of the kext.

 

so find a nearby number, basically one where the first four digits match, which is in my case 8086:2811

 

and insert this number to your DSDT at the right place

 

"device-id",

Buffer (0x04)

{

0x11, 0x28, 0x00, 0x00

}

 

and be aware, that the method DGTP ( which is used here) must be added to your DSDT

[mitch_de]

I found out that using an internal IDE HD with SATA>IDE converter avoids sleep / 10 seconds longer shutdown time. But all other things worked with that converter /HD as it should. Converter is driverless, so no 2GB+ probs or ATA drivers loaded.

[kdawg]

for monitoring the DSDT Speedsteps i found an app called "mark-i" , which is russian only, but you´ll understand.

 

@kt6uk

you need lspci info of you machine ( not the os)

where you get listed the devices ( here from my machine)

 

00:1f.0 ISA bridge [0601]: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller [8086:2810] (rev 02)

 

if AppleLPC is not loaded, the 8086:2810 is not listed in the info.plist of the kext.

 

so find a nearby number, basically one where the first four digits match, which is in my case 8086:2811

 

and insert this number to your DSDT at the right place

 

"device-id",

Buffer (0x04)

{

0x11, 0x28, 0x00, 0x00

}

 

and be aware, that the method DGTP ( which is used here) must be added to your DSDT

Mark-i is old now. You need to use VoodooMonitor.

[mm67]

Mark-i is old now. You need to use VoodooMonitor.

 

I think you are talking about cpu-i which is old version of VoodooMonitor, mark-i is a different program.

[kdawg]

I think you are talking about cpu-i which is old version of VoodooMonitor, mark-i is a different program.

Doh, you're right. Apologies westwaerts.

[MacKonsti]

Guys, can anyone confirm that speed-stepping between iMac5,1 and MacPro3,1 model only plays with the MacPro model? I use either of these in smbios.plist due to my chipset being ICH7. Without changing anything in my DSDT, using iMac5,1 had my processors hotter than usual, compared to using model MacPro3,1. How can this be? Anyone knows something more? Thanks.

[mitch_de]

I use iMac5,1 and have no problems using vanilla speedstepping. CPU stays cool.

I believe beside an functional DSDT PPS+Cstate the Mainboard itself may be i big difference!

Even without speedstep my CPU (C2D 7300, 3.0 OC) never runs hot in low cpu usage conditions !

[XPbIM3]

Does anybody was lucky enough to run SpeedStep under Intel Atom?

 

Was using VoodooPower for a short period - is seemed to switch states ok for me, but caused late speedup when CPU usage was rising and KP sometimes.

 

Any chance to run native AppleIntelCpuPM? 

 

started to digg in DSDT:

 

what that supposed to mean?

 

 

DefinitionBlock ("DSDT.aml", "DSDT", 1, "ACRSYS", "ACRPRDCT", 0x00000001)
{
External (NPSS, IntObj)

Name (SSDT, Package (0x0C)
{
	"CPU0IST ", 
	0x3F380C90, 
	0x0239, 
	"CPU1IST ", 
	0x3F380F10, 
	0xD0, 
	"CPU0CST ", 
	0x3F37FE10, 
	0x01C7, 
	"CPU1CST ", 
	0x3F37EF10, 
	0x83
})
Name (CFGD, 0x013068B1)
Name (PDC0, 0x80000000)
Name (PDC1, 0x80000000)
Name (SDTL, Zero)

 

 

 

 

(already have a list of states, showed by cpu-i or VoodooMonitor)

[ltoolio]

Hey all,

I've been working through FormerlyKnownAs' n00b friendly tutorial and have hit a bit of a roadblock.

 

Specifically, in the section about not seeing AppleLPC in ioreg (which I don't), he suggests to:

Run lspci Tools and look for ISA device - something like:

00:1f.0 ISA bridge [0601]: Intel Corporation Unknown device [8086:3a16]

 

I can't get lspci to run on my machine (I keep getting a message about "cannot find any working access method"), so I used IORegistryExplorer to hunt it down. I'm pretty sure I found it, and I'm pretty sure that it has the same memory address has what FKA mentions:

 

ioreg.tiff

 

However, when I search within my existing DSDT for the same address, I get something far different than what he references:

Device (ISA)
	{
		Name (_ADR, 0x001F0000)
		Name (_UID, 0x0A)
		OperationRegion (P40C, PCI_Config, 0x60, 0x04)
		OperationRegion (P41C, PCI_Config, 0x68, 0x04)
		Device (MBIO)
		{
			Name (_HID, EisaId ("PNP0C01"))
			Name (_UID, 0x0B)
			Method (_CRS, 0, NotSerialized)
			{
				Name (MIO1, ResourceTemplate ()
				{
					IO (Decode16,
						0x0062,			 // Range Minimum
						0x0062,			 // Range Maximum
						0x01,			   // Alignment
						0x02,			   // Length
						)
					IO (Decode16,
						0x0065,			 // Range Minimum
						0x0065,			 // Range Maximum
						0x01,			   // Alignment
						0x0B,			   // Length
						)
					IO (Decode16,
						0x00E0,			 // Range Minimum
						0x00E0,			 // Range Maximum
						0x01,			   // Alignment
						0x10,			   // Length
						)
					IO (Decode16,
						0x0800,			 // Range Minimum
						0x0800,			 // Range Maximum
						0x01,			   // Alignment
						0x60,			   // Length
						)
					IO (Decode16,
						0x0C00,			 // Range Minimum
						0x0C00,			 // Range Maximum
						0x01,			   // Alignment
						0x80,			   // Length
						)
					IO (Decode16,
						0x0860,			 // Range Minimum
						0x0860,			 // Range Maximum
						0x01,			   // Alignment
						0xA0,			   // Length
						)
				})

 

So...I think I'm barking up the wrong tree a bit.

 

Any thoughts?

 

LT

[MacKonsti]

I can't get lspci to run on my machine (I keep getting a message about "cannot find any working access method"), so I used IORegistryExplorer to hunt it down.

Dear ltoolio I also had the same problem with lspci tool, if you've installed it properly and you get this "cannot find any working access method" message, it's because you are running SnowLeo in 64-bit and you've installed the 32-bit version of lscpi. So, either reboot with -x32 or arch=i386 flags (depending on your bootloader) or better, install lspci 64-bit. Just a quick tip--hope it helps.

 

More info on lspci 64-bit for Snow Leopard:

http://osx86.sojugarden.com/2009/10/lspci-...r-1-0-released/

lspci.Installer_v1.0.zip

[ltoolio]

Dear ltoolio I also had the same problem with lspci tool, if you've installed it properly and you get this "cannot find any working access method" message, it's because you are running SnowLeo in 64-bit and you've installed the 32-bit version of lscpi. So, either reboot with -x32 or i=386 flags (depending on your bootloader) or better, install lspci 64-bit. Just a quick tip--hope it helps.

 

More info on lspci 64-bit for Snow Leopard:

http://osx86.sojugarden.com/2009/10/lspci-...r-1-0-released/

 

Thanks, MacKonsti. I installed per your suggestion and now am able to run lspci. However, the results do support what I was seeing when I ran IOreg and the consistency between what I see

 

The output for my lspci is:

00:00.0 Host bridge: Intel Corporation 82Q35 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q35 Express PCI Express Root Port (rev 02)
00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
00:03.2 IDE interface: Intel Corporation 82Q35 Express PT IDER Controller (rev 02)
00:03.3 Serial controller: Intel Corporation 82Q35 Express Serial KT Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9400 GT] (rev a1)

 

If I go off of the LPC interface, which appears to be at the standard mem addy of 0x001F0000, I'm still stuck with something in my DSDT that is drastically different from what FKA's DSDT entry for the LPC.

 

So...I'm at a bit of a loss.

[mitch_de]

"So, either reboot with -x32 or i=386 flags (depending on your bootloader) "

wrong! must be arch=i386 !

[JrCs]

Can someone with a Q6600 try to change the VIDs of he's _PSS method and see if it really change the voltage of the differents states.

I have change this and see only little variation under mark-i (variations due to load of cpu).

With voodoomonitor, i don't have the voltage that i have put under the _PSS method.

I'm using the MacPro3,1 profile, and only fakesmc and AppleHda kext.

 

Thanks for all you guys that can make the test.

[MacKonsti]

(I am not allowed to start a new topic under The X Labs > Intel SpeedStep so please pardon my intrusion)

 

Dear friends, I am trying to optimize my DSDT code, and I recently realised that I've mistakenly included C-states code that my motherboard/mainboard and my Q9550 processor probably don't support.

 

Originally used the code from this thread (thanks to FormerlyKnownAs and everyone else) it seems that my mobo could do P- and C-states successfully, at least that's why I thought until I realised that the BIOS on my Shuttle XPC SG31G2V2 reports only C1E available. Therefore, the code regarding _CST ends from this one:

 

		Name (_CST, Package (0x02)
	{
		0x03,  // Number of C-States (C1/C2/C3 enabled and C4 absent)
		Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x0000,, )}, 0x01, 0x01, 0x03E8},  // C1 State
		Package (0x04) {ResourceTemplate (){Register (SystemIO, 0x08, 0x00, 0x0414,, )}, 0x02, 0x01, 0x01F4},  // C2 State
		Package (0x04) {ResourceTemplate (){Register (SystemIO, 0x08, 0x00, 0x0415,, )}, 0x03, 0x55, 0x00FA}   // C3 State
	})

...to this one:

 

		Name (_CST, Package (0x04)
	{
		0x01,  // Number of C-States (only C1E for Q9550 & ICH7)
		Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x0000,0x01, )}, 0x01, 0x01, 0x03E8},
	})
	// For more on C-States read here:  [url="http://www.hardwaresecrets.com/article/611"]http://www.hardwaresecrets.com/article/611[/url]
	}

and I want to ask the experienced users for their input especially on the code itself and the values used here, because I noticed that different values produce different temperature readings, with significant difference!

 

Can anyone help us by giving us the proper _CST code for us users with only C1E reported, and then explain those numbers in greater detail?

 

For example, especially for the first entry (reading also over at EFI-X Users):

 

Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x0000,0x01, )}, 0x01, 0x01, 0x03E8},

AND

Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x01, 0x02, 0x0000,, )}, 0x01, 0x01, 0x03E8},

produce different temperatures on my Q9550, namely the first one has the first core at around 50C and the second one at around 38C. This could not make sense because when rebooting and entering BIOS, the temperature read-out is around 52C so I guess including numbers 0x01 and 0x02 (after FFixedHW) gives different results but without knowing if it's damaging for the CPU.

 

I tried to read ACPI Spec 4.0.pdf at page 314 but can't get it... Your input will be greatly appreciated!

[keeza]

Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x0000,0x01, )}, 0x01, 0x01, 0x03E8},

 AND

 Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x01, 0x02, 0x0000,, )}, 0x01, 0x01, 0x03E8},

produce different temperatures on my Q9550, namely the first one has the first core at around 50C and the second one at around 38C. This could not make sense because when rebooting and entering BIOS, the temperature read-out is around 52C so I guess including numbers 0x01 and 0x02 (after FFixedHW) gives different results but without knowing if it's damaging for the CPU.

 

I tried to read ACPI Spec 4.0.pdf at page 314 but can't get it... Your input will be greatly appreciated!

 

In my circumstance for C1 I need to use the following code:

 

Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x01,)},One,One,0x03E8},

 

If the above numerals in red are zero then c-states doesn't work/load. I checked this using Ioreg. (cstateinfo) If c-states don't load I get temps of around 48-50 degrees. If c-states load I get temps of around 38 degrees also.

Funny thing is that my ssdt dumps give a FFixedHW address of zero.

mm67's msi board uses these values and it works for me.

[MacKonsti]

In my circumstance for C1 I need to use the following code:

 

Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x01,)},One,One,0x03E8},

 

If the above numerals in red are zero then c-states doesn't work/load. I checked this using Ioreg. (cstateinfo) If c-states don't load I get temps of around 48-50 degrees. If c-states load I get temps of around 38 degrees also.

Funny thing is that my ssdt dumps give a FFixedHW address of zero.

 

mm67's msi board uses these values and it works for me.

Dear keeza, according to ACPI Spec. 4.0.pdf, page 314, the contents of this package are:

 

// ACPI Specs 4.0 (page 314) C-State sub-package:
Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x00000000)}, 0x01, 0x14, 0x03E8},
// Register (Bit Width, Bit Offset, Address, Access Size), C-State Type, Worst-Case Latency, Power Consumption

and according to this and their example given, the last three values are 0x01, 0x14 (20 decimal) and 0x03E8 (1000 decimal) for C1. However, they mention nothing for the contents of the Register. Namely, the values you say (that I also found elsewhere, and also the bit after the address, Access Size). The Spec says it's all zeros for C1.

 

I can take your word that these values are necessary, but I don't know for sure; the Specs point otherwise... And using them, I do get lower temperatures, but could this be virtual and not real? I mean, come on, 15 degrees Celsius is not realistic, or is it? Can you upload us your full code, please?

 

What is the Terminal output of yours, with the command: ioreg | grep -i cstateinfo ? I get nothing.

 

Anyone else to comment on that? What are the proper contents of this Register in the DSDT code? (the one with the FFixedHW, not the one with SystemIO). Cheers.

[keeza]

Dear keeza, according to ACPI Spec. 4.0.pdf, page 314, the contents of this package are:

// ACPI Specs 4.0 (page 314) C-State sub-package:
 Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x00000000)}, 0x01, 0x14, 0x03E8},
 // Register (Bit Width, Bit Offset, Address, Access Size), C-State Type, Worst-Case Latency, Power Consumption

and according to this and their example given, the last three values are 0x01, 0x14 (20 decimal) and 0x03E8 (1000 decimal) for C1.

I'm by no means an expert on this but....

my ssdt dumps included zero values for FFixedHW and 0x01 for latency. (instead of 0x14 that you have). This appears to be in line with section 8.1.2. which states:

"The hardware latency of this state must be low enough that OSPM does not consider the latency aspect of the state when deciding whether to use it."

However, they mention nothing for the contents of the Register. Namely, the values you say (that I also found elsewhere, and also the bit after the address, Access Size). The Spec says it's all zeros for C1.

Thats because C1 is supported by all processors. Yet I need the above values for CStateInfo- why I have no idea.

 

I can take your word that these values are necessary, but I don't know for sure; the Specs point otherwise... And using them, I do get lower temperatures, but could this be virtual and not real? I mean, come on, 15 degrees Celsius is not realistic, or is it? Can you upload us your full code, please?

My dsdt is in my sig. I've said before that I believe that the majority with vanilla power management have C1 only, myself included, even if their processor supports C2,C3 or C4. The only basis I have for saying that C1 is enabled is CStateInfo value in Ioreg and the lower temps.

What is the Terminal output of yours, with the command: ioreg | grep -i cstateinfo ? I get nothing.

Both on my hack and my imac I get nothing.

[mitch_de]

Interesting C1 informations (again ) thanks.

I also believe that there are at least 2-3 little different settings out for using C1.

My looks like ( copied from somewhere here) :

Return (Package (0x02)

{

0x1,

Package (0x4){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x00,,)},One,0x9D,0x3E8}

})

But as the other, i am unsure what the "normal" parameters for C1 are.

I dont remember what 0x9D was needed, only for C1 or only for the lines with 3 C-States ?

At least the cpu run

 

Would be nice if someone help that we get again to an standard C1 parameter line.

[keeza]

Interesting C1 informations (again ) thanks.

I also believe that there are at least 2-3 little different settings out for using C1.

My looks like ( copied from somewhere here) :

Return (Package (0x02)

{

0x1,

Package (0x4){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x00,,)},One,0x9D,0x3E8}

})

But as the other, i am unsure what the "normal" parameters for C1 are.

I dont remember what 0x9D was needed, only for C1 or only for the lines with 3 C-States ?

At least the cpu run

 

Would be nice if someone help that we get again to an standard C1 parameter line.

 

@Mitch_de, if you used this:

 

Package (0x4){ResourceTemplate (){Register (FFixedHW,0x00,0x00,0x00,,)},One,0x9D,0x3E8}

 

Would you break Cstates?

 

Regarding the 0x9D, ACPI 8.4.2.1. says regarding the latency value:

"The worst-case latency to enter and exit the C State (in microseconds). There are no latency restrictions." So I don't think that this value would impede C1 but may hinder C2 and C3 if latency value is too low.

 

I read this just now:

8.4.2.1 _CST (C States)

_CST is an optional object that provides an alternative method to declare the supported processor power states (C States). Values provided by the _CST object override P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT. The _CST object allows the number of processor power states to be expanded beyond C1, C2, and C3 to an arbitrary number of power states

 

Does that suggest that _CST may not be needed and that OSX should read Cstate info from P_Blk & P_LVL registers???

[mm67]

Dear keeza, according to ACPI Spec. 4.0.pdf, page 314, the contents of this package are:

 

// ACPI Specs 4.0 (page 314) C-State sub-package:
Package (0x04) {ResourceTemplate (){Register (FFixedHW, 0x00, 0x00, 0x00000000)}, 0x01, 0x14, 0x03E8},
// Register (Bit Width, Bit Offset, Address, Access Size), C-State Type, Worst-Case Latency, Power Consumption

and according to this and their example given, the last three values are 0x01, 0x14 (20 decimal) and 0x03E8 (1000 decimal) for C1. However, they mention nothing for the contents of the Register. Namely, the values you say (that I also found elsewhere, and also the bit after the address, Access Size). The Spec says it's all zeros for C1.

 

I can take your word that these values are necessary, but I don't know for sure; the Specs point otherwise... And using them, I do get lower temperatures, but could this be virtual and not real? I mean, come on, 15 degrees Celsius is not realistic, or is it? Can you upload us your full code, please?

 

What is the Terminal output of yours, with the command: ioreg | grep -i cstateinfo ? I get nothing.

 

Anyone else to comment on that? What are the proper contents of this Register in the DSDT code? (the one with the FFixedHW, not the one with SystemIO). Cheers.

 

This document will tell you the meaning of register values: http://download.intel.com/technology/IAPC/...ds/30222305.pdf

 

Register with all zeros means C1, register with 0x1,0x2,0x00 means C1E. And defining C1 is pointless since all cpu's support it anyway.