DSDT - Vanilla Speedstep - Generic Scope (_PR)

[yonika]

Hellooo ?

 

Could someone help with the following question ?

 

Yesterday i fixed my hpet on the dsdt to use the cpupm kext, then i've seen what you guys are talking about with the _cst error. later on I found in my bios that there are options to enable c2,c3,c4 and maybe c5 states, so I enabled it, and there was no cst error on boot. I did not alter my dsdt in any other way nor made any change to the SMC plugin, does it mean that my system now works with c-states ? Do I have to do anything else ? I did notice with cpu-i that my system is now on full power (multiplier is on x9) before the change I had 2 steps out of the box x6 and x9 and most of the time was x6.

Do I have to do anything else in order to bring speed stepping back to operation ? do i still need to add the PSS to my DSDT ?

 

10x in advance,

Jonathan

 

Could someone please be kind and help ?

[WinstonAce]

Something similar happened to me

I've enabled all the C stats in the bios and got rid of the cst error upon boot

I've added applecpupowermanagment disabler to my system and the strange thing is that now I have speedstep - the multiplier and the voltage are lowering themself in idle without any ssdt tables in my dsdt

 

The down side is that I lost the ability for deep sleep but I think it's worth it.

[Master Chief]

Ok, so I tested the DSDT I attached earlier with the P-states and the C-state object added and I dont' see any evidence of stepping and I'm getting garbled playback in iTunes unless I'm moving the mouse around like a mad-man.

You mean that you don't see any changes in CPU-i? Please note that this forum does not show sig info when I replied to you, so I have really no idea what OS you are using.

 

TIP: You may want to add a link or the post number next time, because I don't have the time to search for that post.

 

Edit: I checked you sig and you seem to be using Snow Leopard. I also see this little note: "Not working: DSDT Speedstep, 32-bit". Making me wonder if it works in 64 bit mode. You only have this: "garbled playback in iTunes" in 32 bit mode?

 

Where do I set the C-state latency values in the CST object with the ones dumped in my FACP table?

Have a look at post #58 and don't forget to read #46 as well. What is the C2 and C3 latency in the FACP?

[SA22C]

You mean that you don't see any changes in CPU-i? Please note that this forum does not show sig info when I replied to you, so I have really no idea what OS you are using.

 

TIP: You may want to add a link or the post number next time, because I don't have the time to search for that post.

 

Edit: I checked you sig and you seem to be using Snow Leopard. I also see this little note: "Not working: DSDT Speedstep, 32-bit". Making me wonder if it works in 64 bit mode. You only have this: "garbled playback in iTunes" in 32 bit mode?

 

 

Have a look at post #58 and don't forget to read #46 as well. What is the C2 and C3 latency in the FACP?

 

I can't boot into 32-bit at all. For whatever reason, my system boots normally until loginwindow and then the GUI fails to render. The system is still responsive, but I can't interact with it. Booting into safe mode gets me into the GUI, but I can't use apps like CPU-i in safe mode. The garbled playback in iTunes is present in 64-bit and I can't test 32 bit because of the aforementioned difficulties in getting into 32-bit mode.

 

Here are the pertinent entries in my FACP table:

 

[05Fh 095 1] _CST Support : E3

[060h 096 2] C2 Latency : 0065

[062h 098 2] C3 Latency : 03E9

[Master Chief]

I can't boot into 32-bit at all. For whatever reason, my system boots normally until loginwindow and then the GUI fails to render. The system is still responsive, but I can't interact with it. Booting into safe mode gets me into the GUI, but I can't use apps like CPU-i in safe mode. The garbled playback in iTunes is present in 64-bit and I can't test 32 bit because of the aforementioned difficulties in getting into 32-bit mode.

You should (try to) fix that (not here of course).

 

Here are the pertinent entries in my FACP table:

[05Fh 095 1] _CST Support : E3

[060h 096 2] C2 Latency : 0065

[062h 098 2] C3 Latency : 03E9

That's the same as I have here (see port #83). And this basically means that there is no C2/C3 State support in our BIOS. As in it does not include a CST object. And that was why we had the following errors in our log file:

ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

The good news is that we already learned how to add this missing _CST object, but we still have to figure out what to do with it. At least now we know when there is no CST object.

 

Entering a C-State can be done in two ways; either by using a P_BLK based C state control method, or by using a _CST based C state control method. Let's first have a look at the first, most basic method. But before we continue, let's have a look at one of my DSDT's processors blocks:

Processor (CPU1, 0x01, 0x00000810, 0x06)

The third argument here (0x00000810) is the most important one. And all it takes to enter C2 is a single read (1 byte) from address 0x00000814 (P_BLK + 4 aka P_LVL2). To enter C3 is equally easy, but then it has to read a byte from 0x00000815 (P_BLK + 5 aka P_LVL3). But this won't work when the latency in FACP is greater than 100 for C2, or 1000 for C3 (see my post #46).

 

The good news (again) is that we can override these values, which is the second method of entering C-States . One of the things this method needs is a _CST object. No worries, because this object should by now already be part of your modified DSDT. Let's have a look at the first ResourceTemplate in my _PCT object, which looks like this:

			ResourceTemplate () // Native PCT
		{
			Register (FFixedHW, 
				0x40,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000199, // Address of PERF_CTRL register
				,)
		},

This simply overrides the default P_BLK (0x00000810) and thus we might need to follow the same logic (P_BLK + 4/5 aka P_LVLn for C2/3) to enter a Cn state. What if we use this information, and put it into the our newly added _CST object like this :

			ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x08,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000814, // Enter C2
				,)
		},

And like this for C3:

			ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x08,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000815, // Enter C3
				,)
		},

Would that work?

 

No, I did not try it myself. Not yet that is (I first have to do a lot of reading, to understand things, and to get to the bottom of it). The main problem for me is the lack of proper latency values, since the values in my FACP are of no use. In fact they simply prevent OSPM from entering C2/C3. We might be able to tackle this... if only people with _CST objects in their SSDT made dumps available of their DSDT/SSDT and FACP table.

 

Note: Your MB's BIOS must at least support C1 to get to C2/3, and the first CPU (core) should never enter C2/C3 (this will be my next target).

 

EDIT: Woohoo!!! I verified my findings on a real MacPro and I was right! The address info I was looking for was right in my face, I however used the wrong values. Fixed.

[Master Chief]

Could someone please be kind and help ?

Start by adding a signature (in your profile) so that people here know what you are using

[Superhai]

Would that work?

 

You are just guessing, and it makes no sense...

 

What a thread this is, I think you should separate your P-states and C-states, they are not the same fish (it is hard to read this thread because of that). And it is not in your ACPI either.

[Master Chief]

You are just guessing, and it makes no sense...

You just have to take that back, because everything I wrote can be found – and thus verified – in either the ACPI specification and/or programmers manual. And not only that, but I found out that I was right, but I accidentally used the wrong address (they should have been 0x00000814 and 0x00000815). My mistake.

 

To anyone who wants to verify my findings... be my guest. And in mean time... I'll let it drop to C3 during the movie

[Superhai]

You just have to take that back, because everything I wrote can be found – and thus verified – in either the ACPI specification and/or programmers manual. And not only that, but I found out that I was right, but I accidentally used the wrong address (they should have been 0x00000814 and 0x00000815). My mistake.

 

Anyone that wants to verify my findings... be my guest

 

Who am I to question your authority on this subject. ;-)

 

Anyway, _PCT is not related to C-states (or the _CST object) they are used for controlling P-states.

[yonika]

Start by adding a signature (in your profile) so that people here know what you are using

 

O.k

 

I've added my signature,

Anyway, I have a EP45T-DSR3 board, this is what i've done/tried so far, but no luck in speedstepping:

 

1. Added HPET fix to DSDT, this allowed loading of AppleIntelCPUPowerManagement.kext and sleep, but with cst evaluation error and no speedstepping in cpu-i (allways on x9)

2. Enabled all c-states in my bios's advanced options, this removed the cst evaluation error in boot, still no speedstepping in cpu-i (allways on x9)

3. Extracted all SSDT's using Ubuntu liveCD, got IST, CST and CPUPM, on PSS tables I have only 2 steps (x6 and x9), appended all SSDTs to the end of my DSDT.dsl, compiled with no errors, added the dropSSDT=y to my kernel flags. still max at x9 on cpu-i.

4. my PSS includes SPSS and NPSS, tried to fix SPSS (last two values looked wrong), still the same, max on x9.

5. changed smc platform plugin's Info.plist to MacPro 3,1 like in my injected smbios.plist, nothing, still on x9.

6. tried fixing the addresses of the PREF_CTL and PREF_STATUS registers to 199 and 198, tried to change all the places where i thought it should've been changed, still nothing, speed at x9.

 

It's important to say that with NullCPUPowerManagement, I have 2 steps working, x6, and x9, without touching the DSDT at all.

this is really frustrating, it feels so close to having a major step into vanilla system, but yet it's still far, I don't want my cpu's getting hot all the time.

 

Please help ,

10x,

Jonathan

 

My signature does not show automatically for some reason, so here it is:

________________________________________________________________________________

_____________

GA-EP45T-DS3R: BIOS F2, Core 2 Duo E8400 3.0 GHz, 4GB RAM DDR3, Asus nVidia 8600GT 512MB DDR3, running Mac OS X Snow Leopard 10.6.1, vanilla installation using retail DVD on USB Stick, Chameleon EFI 2.0 RC1. ALC889a working.

[Master Chief]

O.k

 

I've added my signature,

Anyway, I have a EP45T-DSR3 board, this is what i've done/tried so far, but no luck in speedstepping:

 

...

Please help ,

10x,

Jonathan

Hi Jonathan,

 

Please attach a ZIP file with all the originally extracted files and your modified dsdt.dsl and I will have a look at it.

 

 

Anyway, _PCT is not related to C-states (or the _CST object) they are used for controlling P-states.

You are right!

 

The reason for this was section 4.7.1 (ACPI Register Summary) in the ACPI specifications. Which reads: "Address (relative to register block)" (see table 4-6 Processor Control Registers) and thus I simply assumed* that by using a _PCT object, which changes the P_CNT address, that the pointers to P_LVLn would have changed. Not true.

[Beerkex'd]

I looked at FormerlyKnownAs' DSDT and tried to insert my SSDT data in the same way. I believe I have all the required tables (please correct me if I'm wrong).

 

The DSDT compiles with no warnings or errors, but when I boot with DropSSDT=y it takes a lot longer than usual for the desktop to appear and I get horrible broken up sound in iTunes:

 

9/13/09 01:23:48 kernel IOAudioStream[0x4656600]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (17,623)->(18,626).

9/13/09 01:23:48 kernel IOAudioStream[0x4656600]::clipIfNecessary() - adjusting clipped position to (18,623)

 

sysctl -a | grep freq shows the same as always:

 

kern.exec: unknown type returned

hw.busfrequency = 1332000000

hw.cpufrequency = 3166000000

hw.tbfrequency = 1000000000

hw.tbfrequency: 1000000000

hw.cpufrequency_max: 3166000000

hw.cpufrequency_min: 3166000000

hw.cpufrequency: 3166000000

hw.busfrequency_max: 1332000000

hw.busfrequency_min: 1332000000

hw.busfrequency: 1332000000

 

These messages have gone though:

 

9/12/09 22:29:36 kernel ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed

9/12/09 22:29:36 kernel ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

I hope you guys can help me spot what I've done wrong..almost bleeding out of my ears here.

I'll try removing CPUs 3 and 4 to begin with but I don't think that will matter much.

dsdt_BK.zip

 

My ACPI dumps and a dsdt.dsl without the SSDT stuff (including FACP) is here:

http://www.insanelymac.com/forum/index.php...t&p=1258828

[Master Chief]

...

 

The DSDT compiles with no warnings or errors, but when I boot with DropSSDT=y it takes a lot longer than usual for the desktop to appear and I get horrible broken up sound in iTunes:

 

...

 

I hope you guys can help me spot what I've done wrong..almost bleeding out of my ears here.

I'll try removing CPUs 3 and 4 to begin with but I don't think that will matter much.

Do you have a core solo processor? If not then it can't seem to find the second core. Have a look at this:

Processor (P002, 0x02, 0x00000000, 0x00) {}

and this:

Name (NPCP, 0x00000001)

The latter one can be found in: acpi_ssdt05_CpuPm.dsl

 

p.s. I haven't really looked at other possible issues, but it is time to go to bed for me

[yonika]

Hi Jonathan,

 

Please attach a ZIP file with all the originally extracted files and your modified dsdt.dsl and I will have a look at it.

 

O.k, I'm attaching the following files

 

1. A zip with the SSDTs I extracted from ubuntu.

2. A zip with a few DSDTs

a. The DSDT before i started playing with HPET and SSDTs

b. Modified DSDTs i've tried with stages of just merging the SSDTs,

trying to fix the SPSS, and trying to fix the register addresses to 199 and 198.

 

I really thank you for having the time to look at my files and help.

 

Thanks in advance,

Jonathan

DSDT_files.zip

SSDT_files.zip

[Beerkex'd]

Thanks for looking, it is much appreciated. My ears aren't bleeding from the skipping sound, it's my brain turning to mush from looking at ACPI tables and reading, reading and reading..

 

Do you have a core solo processor? If not then it can't seem to find the second core.

 

It's a Core 2 Duo E8500. The CPUs in Scope (\PR) were always like this (except I changed P00x to CPUx):

 

Scope (_PR)

{

Processor (CPU1, 0x01, 0x00000810, 0x06) {}

Processor (CPU2, 0x02, 0x00000000, 0x00) {}

Processor (CPU3, 0x03, 0x00000000, 0x00) {}

Processor (CPU4, 0x04, 0x00000000, 0x00) {}

}

 

In the DSDT tables I've looked at from real Macs both cores are declared in Scope (_PR) with 410 and 0x06.

 

Should I do the same thing FormerlyKnownAs did (cp'd from his DSDT in the first post):

 

Scope (_PR)

{

Processor (CPU0, 0x00, 0x00000410, 0x06) {}

Processor (CPU1, 0x01, 0x00000410, 0x06) {}

Processor (CPU2, 0x02, 0x00000410, 0x06) {}

Processor (CPU3, 0x03, 0x00000410, 0x06) {}

 

I tried changing CPU1 to CPU0 earlier today but then I couldn't boot, it halted with at a CPU error message right at the beginning.

I didn't try changing the rest though, I will try later - do you know what the 410/810 value means?

 

The "Name (NPCP, 0x00000001)" is already in the DSDT I posted but the compiler has changed 0x00000001 to "One".

Should changed it to 0x00000002? Or what did you mean...I'm just barely on my way to enlightenment with a melting brain so this stuff is difficult to follow.

When the DSDT was loaded both cores were showing in IORegistryExplorer (that is to say, the second one had an "AppleACPICPU" attached as usual). I didn't check Activity Monitor at the time.

I'm using iMac9,1 as model identifier - does that mean that I have to use CStates from an iMac9,1?

[Superhai]

There are a few things about C-states that makes issues. Crackled sound is an indication that you are in fact putting the CPU in a lower powered C-state (usually from C2 and lower), as the TSC stops counting. You need HPET or some other timing to be precise, and be sure that TSC is updated when returning to C0.

 

You also need to make the difference between SystemIO and FFixedHW (and other values).

SystemIO

Is related to the x86 I/O ports, and are defined by your chipset setup (which means that different m/b will have different values)

FFixedHW

That is some fixed hardware, for x86 CPU's it is often used for MSR's. And as you have seen for P-states, the MSR used are the 0x0198 (IA32_PERF_STATUS) and 0x0199 (IA32_PERF_CTL) (on AMD other MSR's are used)

SystemMemory

This is the system memory.

EmbeddedControl, SMBus, PCI_Config

Other devices that OSPM will communicate with. And very dependant on your particular m/b.

 

 

I tried changing CPU1 to CPU0 earlier today but then I couldn't boot, it halted with at a CPU error message right at the beginning.

I didn't try changing the rest though, I will try later - do you know what the 410/810 value means?

 

If you change CPU name you have to do it in every instance in your ACPI tables. port 0x410 or 0x810 is the cpu I/O port block and the number after is its length (so "0x410, 6" means a block of 6 ports from 0x410 to 0x416)

[ivik]

Thanks for looking, it is much appreciated. My ears aren't bleeding from the skipping sound, it's my brain turning to mush from looking at ACPI tables and reading, reading and reading..

 

 

 

It's a Core 2 Duo E8500. The CPUs in Scope (\PR) were always like this (except I changed P00x to CPUx):

 

Scope (_PR)

{

Processor (CPU1, 0x01, 0x00000810, 0x06) {}

Processor (CPU2, 0x02, 0x00000000, 0x00) {}

Processor (CPU3, 0x03, 0x00000000, 0x00) {}

Processor (CPU4, 0x04, 0x00000000, 0x00) {}

}

 

In the DSDT tables I've looked at from real Macs both cores are declared in Scope (_PR) with 410 and 0x06.

 

Should I do the same thing FormerlyKnownAs did (cp'd from his DSDT in the first post):

 

Scope (_PR)

{

Processor (CPU0, 0x00, 0x00000410, 0x06) {}

Processor (CPU1, 0x01, 0x00000410, 0x06) {}

Processor (CPU2, 0x02, 0x00000410, 0x06) {}

Processor (CPU3, 0x03, 0x00000410, 0x06) {}

 

I tried changing CPU1 to CPU0 earlier today but then I couldn't boot, it halted with at a CPU error message right at the beginning.

I didn't try changing the rest though, I will try later - do you know what the 410/810 value means?

 

The "Name (NPCP, 0x00000001)" is already in the DSDT I posted but the compiler has changed 0x00000001 to "One".

Should changed it to 0x00000002? Or what did you mean...I'm just barely on my way to enlightenment with a melting brain so this stuff is difficult to follow.

When the DSDT was loaded both cores were showing in IORegistryExplorer (that is to say, the second one had an "AppleACPICPU" attached as usual). I didn't check Activity Monitor at the time.

I'm using iMac9,1 as model identifier - does that mean that I have to use CStates from an iMac9,1?

Try this dsdt and drop ssdt tables.

dsdt.txt

[Master Chief]

Thanks for looking, it is much appreciated. My ears aren't bleeding from the skipping sound, it's my brain turning to mush from looking at ACPI tables and reading, reading and reading.

No problem. I hear you. And yes it does indeed require a lot of reading, but that's just a fun part of hacking isn't it

 

It's a Core 2 Duo E8500. The CPUs in Scope (\PR) were always like this (except I changed P00x to CPUx):

 

Scope (_PR)

{

Processor (CPU1, 0x01, 0x00000810, 0x06) {}

Processor (CPU2, 0x02, 0x00000000, 0x00) {}

Processor (CPU3, 0x03, 0x00000000, 0x00) {}

Processor (CPU4, 0x04, 0x00000000, 0x00) {}

}

Which is fine. And the way these processor blocks are declared is 100% valid. The question now is if this will work with the ACPI_SMC_PlatformPlugin.kext My gut feeling might be wrong, but it says nope, since all DSDT files I have seen thus far declare it like this:

	Scope (_PR)
{
	Processor (CPU1, 0x01, 0x00000810, 0x06) {}
	Processor (CPU2, 0x02, 0x00000810, 0x06) {}
}

Note that I copied the PBlockAddres from your first and only (boot) CPU which is the correct address for your MB, otherwise it won't even boot (hangs at Apple logo).

 

In the DSDT tables I've looked at from real Macs both cores are declared in Scope (_PR) with 410 and 0x06.

 

Should I do the same thing FormerlyKnownAs did (cp'd from his DSDT in the first post):

 

Scope (_PR)

{

Processor (CPU0, 0x00, 0x00000410, 0x06) {}

Processor (CPU1, 0x01, 0x00000410, 0x06) {}

Processor (CPU2, 0x02, 0x00000410, 0x06) {}

Processor (CPU3, 0x03, 0x00000410, 0x06) {}

No. You must use the proper PBlockAddress. Don't use anything else.

 

I tried changing CPU1 to CPU0 earlier today but then I couldn't boot, it halted with at a CPU error message right at the beginning.

The first argument of a Processor declaration opens a name scope with that name, so like Superhai already said: You have to change it everywhere when you change it. There is however no need for it.

 

I didn't try changing the rest though, I will try later - do you know what the 410/810 value means?

From the ACPI specification:

 

"Syntax

Processor (ProcessorName, ProcessorID, PBlockAddress, PblockLength)

{ObjectList}

Arguments

Declares a named processor object named ProcessorName. Processor opens a name scope. Each processor

is required to have a unique ProcessorID value that is unique from any other ProcessorID value.

 

For each processor in the system, the ACPI BIOS declares one processor object in the namespace anywhere

within the \_SB scope. For compatibility with operating systems implementing ACPI 1.0, the processor

object may also be declared under the \_PR scope. An ACPI-compatible namespace may define Processor

objects in either the \_SB or \_PR scope but not both.

 

PBlockAddress provides the system I/O address for the processors register block. Each processor can

supply a different such address. PBlockLength is the length of the processor register block, in bytes and is

either 0 (for no P_BLK) or 6. With one exception, all processors are required to have the same

PBlockLength. The exception is that the boot processor can have a non-zero PBlockLength when all other

processors have a zero PBlockLength. It is valid for every processor to have a PBlockLength of 0."

 

The "Name (NPCP, 0x00000001)" is already in the DSDT I posted but the compiler has changed 0x00000001 to "One".

Should changed it to 0x00000002? Or what did you mean...I'm just barely on my way to enlightenment with a melting brain so this stuff is difficult to follow.

Yes, change it to 0x02 when you've changed the Processor declarations. And hang in.... we're slowly getting somewhere.

 

When the DSDT was loaded both cores were showing in IORegistryExplorer (that is to say, the second one had an "AppleACPICPU" attached as usual). I didn't check Activity Monitor at the time.

Just AppleACPICPU? That would mean that P-State stepping isn't even working for you. Is it?

 

For you info: I also have ACPI_SMC_PlatformPlugin, AGPMEnabler and AGPMController (See attachments: BTW how do I move attachments to this spot?)

 

I'm using iMac9,1 as model identifier - does that mean that I have to use CStates from an iMac9,1?

I don't think so, but I thought of having seen evidence in the ACPI_SMC_PlatformPlugin.kext (Info.plist) that (certain) iMac's have limited PM capabilities.

[Master Chief]

O.k, I'm attaching the following files

 

1. A zip with the SSDTs I extracted from ubuntu.

2. A zip with a few DSDTs

a. The DSDT before i started playing with HPET and SSDTs

b. Modified DSDTs i've tried with stages of just merging the SSDTs,

trying to fix the SPSS, and trying to fix the register addresses to 199 and 198.

 

I really thank you for having the time to look at my files and help.

 

Thanks in advance,

Jonathan

The original files appear to be fine. You might want to add a change _PSS object – one with more P-States – but that's apparently all you need.

 

1) Did you enable C States in your BIOS? And if that's a yes, then which one(s)? Edit: Already answered in post #125

2) What model do you see in System Profiler? Edit: Already answered in post #135

3) Can you please add a FACP dump for me?

4) Open IORegistryExplorer (part of Xcode) and check for the items in my two screen shots, do you see the same items there?

 

n.b. If you don't see the items listed in my screen shots (in post #143) then your changes in Info.plist aren't working.

 

p.s. Feel free to attach your modified Info.plist to see if I can spot the error

[Beerkex'd]

Master Chief, thanks, I will try what you said and see what happens.

 

I do have the ACPI_SMC_PlatformPlugin, AGPMEnabler and AGPMController as well but they only appear under CPU1. CPU2 only has the AppleACPICPU. I don't, however have "CSTInfo" like you..hmm

 

I have P-state switching and proper shutdown when using VoodooPowerMini.kext (thanks Superhai). Without VoodooPower it runs at full throttle and doesn't shut down completely (the classic "lights go off but CPU fan keeps running").

 

Try this dsdt and drop ssdt tables.

 

Did you make it? What CPU is installed on the P5Q-E it was taken from, and does AppleLPC.kext load on it?

You have to change a device ID in the kext, or you can patch it in the DSDT (excerpt from mine below).

I thought AppleLPC.kext needed to be loaded for C-state switching to work at all?

 

			Device (LPCB)
		{
			Name (_ADR, 0x001F0000)
			Method (_DSM, 4, NotSerialized)
			{
				Store (Package (0x02)
					{
						"device-id", 
						Buffer (0x04)
						{
							0x18, 0x3A, 0x00, 0x00
						}
					}, Local0)
				DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				Return (Local0)
			}

			Device (IELK)
			{ (....)

The main difference I can see from your method and mine is that you inserted the whole thing inside Scope _PR instead of at the end of the DSDT.

I copied your entire Scope _PR and also your HPET device to my DSDT (it is very different from mine).

 

I don't get the evaluation errors on boot (with or without DropSSDT=y) and there is no break-up in the sound, but there is no state changing either, it's running at full throttle. CPU temps went up by 4-5 degrees Celsius.

 

Your HPET (SBRG changed to LPCB for AppleLPC.kext):

				Device (HPET)
			{
				Name (_HID, EisaId ("PNP0103"))
				Name (CRS, ResourceTemplate ()
				{
					IRQNoFlags ()
						{0}
					IRQNoFlags ()
						{8}
					Memory32Fixed (ReadOnly,
						0xFED00000,		 // Address Base
						0x00000400,		 // Address Length
						_Y0D)
				})
				OperationRegion (^LPCR, SystemMemory, 0xFED1F404, 0x04)
				Field (LPCR, AnyAcc, NoLock, Preserve)
				{
					HPTS,   2, 
						,   5, 
					HPTE,   1, 
							Offset (0x04)
				}

				Method (_STA, 0, NotSerialized)
				{
					If (LEqual (OSFL (), Zero))
					{
						If (HPTE)
						{
							Return (0x0F)
						}
					}
					Else
					{
						If (HPTE)
						{
							Return (0x0B)
						}
					}

					Return (Zero)
				}

				Method (_CRS, 0, NotSerialized)
				{
					CreateDWordField (CRS, \_SB.PCI0.LPCB.HPET._Y0D._BAS, HPT)
					Multiply (HPTS, 0x1000, Local0)
					Add (Local0, 0xFED00000, HPT)
					Return (CRS)
				}
			}

 

My old HPET:

			   Device (HPET)
			{
				Name (_HID, EisaId ("PNP0103"))
				Name (ATT3, ResourceTemplate ()
				{
					IRQNoFlags ()
						{0}
					IRQNoFlags ()
						{8}
					Memory32Fixed (ReadWrite,
						0xFED00000,		 // Address Base
						0x00000400,		 // Address Length
						)
				})
				Name (ATT4, ResourceTemplate ()
				{
				})
				Method (_STA, 0, NotSerialized)
				{
					Return (0x0F)
				}

				Method (_CRS, 0, NotSerialized)
				{
					Return (ATT3)
				}
			}

 

I think I will keep trying with my previous method but use your HPET, seeing as it talks to the LPC.

 

Here's my DSDT with your HPET and Scope _PR:

ivik_beer_mashup.zip

[yonika]

The original files appear to be fine. You might want to add a change _PSS object – one with more P-States – but that's apparently all you need.

 

1) Did you enable C States in your BIOS? And if that's a yes, then which one(s)? Edit: Already answered in post #125

2) What model do you see in System Profiler? Edit: Already answered in post #135

3) Can you please add a FACP dump for me?

4) Open IORegistryExplorer (part of Xcode) and check for the items in my two screen shots, do you see the same items there?

 

n.b. If you don't see the items listed in my screen shots (in post #143) then your changes in Info.plist aren't working.

 

p.s. Feel free to attach your modified Info.plist to see if I can spot the error

 

O.k O.k, I think I am now the happiest man in the entire region, or as happy as one can be from seeing numbers jump from x6 to x9 and vice versa

 

Well, first I'll say what happened, then I'll ask more questions

 

I noticed in your message that you said I answered your question about system profiler in post #135, then I said to myself, Hey, I don't remember checking in the system profiler, so I did, and I saw it was on MacPro2,1.

Then I checked my smbios.plist and saw that it was really on 2,1 and not 3,1 (it turns out, I changed the file on the wrong partition) I changed it to 3,1 and Bam, it started jumping with multipliers and voltage.

Then I said to myself, are all the changes I tried really necessary to make it work ? and tried removing changes one by one.

I ended with the following:

smbios.plist with MacPro3,1.

No change at all in AppleSMC plugin

CPUPM SSDT in DSDT (although I did not try to remove that one yet)

CPUISTx2 SSDTs in DSDT with an SPSS fix to look almost like NPSS (fixed last two values for each step, without this it did not work).

No CST method in the DSDT at all (still no CST evaluation error on boot)

No dropSSDT=yes flag on boot or com.apple.Boot.plist

 

Now for the questions:

1. where do I find more p-states for my E8400 CPU ? is there any intel's official place it is written in ? any kind of database ?

2. How come it works without all the stuff I mentioned ? the SMC plugin change, the dropSSDT flag ? are all these actually unnecessary ?

3. How do I know if C-states work besides not having the error on boot ? is there an application that shows that ?

4. Before the success, I dumped the FACP (attached) and saw that it says "_cst support: 0" what does this mean ?

Do i have c-states or not ???

5. I read that deep sleep works when using the AppleIntelCPUPowerManagement.kext, how do I enable or go into it ?

6. Last question, what is AppleLPC.kext ? I saw it here, and asked myself if i'm missing something important ?

 

 

Anyway, here are my files attached if someone wants to take a look,

 

Thanks in advance,

Jonathan

FACP.zip

Hack_Files___Success.zip

[ivik]

Beerkex'd,

 

DSDT and SSDT are your's, patched with dsdt patcher and added _CST and _PSS. I have done the same thing with my dsdt, and it is cool like in windows/linux.

 

Do you have CPUPLimit set to 0 in your ioreg? Do you have PerformanceStateArray and stepper data in ioreg?

You could try replacing NPSS with SPSS.

 

Also try deleting in HPET Method (_STA, 0, NotSerialized) all, and leave just:

                    Method (_STA, 0, NotSerialized)
                   {
                    Return (0x0F)
                   }

 

Also try reduce number of CPU's. I have core solo, and i don't know how core duos / C2d are handled.

[William Parker]

Have you made any progress using just p-states alone, if so how did you get the values for the fractional multiplier?

 

@formerlyknownas Great thread, but is there another app besides p-state calculator that will allow fractional multipliers? The Q9550 has six p-states. with multipliers of 6, 6.5, 7, 7.5, 8 and 8.5.

 

Without any editing of the dsdt and with nullcpupm in my extra folder CPU-i is showing a change from 6x at idle to 8.5 under load. The multiplier/freq is changing but the voltage always remains at the highest p-state.

 

@william parker

I am just delving into the speedstep myself. Also with the Q9550 processor. Since p-state setting are processor dependent... Please keep posted if you make any progress.

[Master Chief]

Have you made any progress using just p-states alone, if so how did you get the values for the fractional multiplier?

I think that I already explained that in post #118

 

O.k O.k, I think I am now the happiest man in the entire region, or as happy as one can be from seeing numbers jump from x6 to x9 and vice versa

 

...

 

Now for the questions:

1. where do I find more p-states for my E8400 CPU ? is there any intel's official place it is written in ? any kind of database ?

2. How come it works without all the stuff I mentioned ? the SMC plugin change, the dropSSDT flag ? are all these actually unnecessary ?

3. How do I know if C-states work besides not having the error on boot ? is there an application that shows that ?

4. Before the success, I dumped the FACP (attached) and saw that it says "_cst support: 0" what does this mean ?

Do i have c-states or not ???

5. I read that deep sleep works when using the AppleIntelCPUPowerManagement.kext, how do I enable or go into it ?

6. Last question, what is AppleLPC.kext ? I saw it here, and asked myself if i'm missing something important ?

...

1) You'll either have to use the P-State Calculator (link in post #1) or use a calculator.

2) You MB/BIOS supports C1/C2 and C3 (check the latency in the FACP and post #46) so you don't need it.

3) The power should drop to either 1.000 (C2) or 0.500 (C3) in CPU-i.

4) Probably that CST is natively supported, but there's no documentation about this value.

5) You can check it with pmset -g | grep hibernatemode and change it with sudo pmset -a hibernatemode n* or use the Deep Sleep Widget.

6) This appears to be something that lowers the temperature a little, but I don't know, yet, what it really does or is used for.

 

*Here are the values (from deepsleep.pdf) and the meaning of it:

 

• 0 (quick): Default sleep behavior on most Apple computers. RAM is still powered on while sleeping. Wake up is fast. Safe sleep is disabled.

• 1 (deep): Hibernation behavior. System is totally shut down while sleeping. RAM contents are dumped to disk. Wake up is slow.

• 3 (safe): Default behavior on Powerbook HD and later computers. RAM is still powered on while sleeping. Wake up is fast. Safe sleep is enabled, so RAM contents are also dumped to disk before going to sleep.

• 5 (deep): Same as mode 1 for systems with encrypted virtual memory.

• 7 (safe): Same as mode 3 for systems with encrypted virtual memory.

 

Master Chief, thanks, I will try what you said and see what happens.

 

I do have the ACPI_SMC_PlatformPlugin, AGPMEnabler and AGPMController as well but they only appear under CPU1. CPU2 only has the AppleACPICPU. I don't, however have "CSTInfo" like you..hmm

I have not found any information about CSTInfo as of yet i.e. I don't know exactly what it does/means.

 

I have P-state switching and proper shutdown when using VoodooPowerMini.kext (thanks Superhai). Without VoodooPower it runs at full throttle and doesn't shut down completely (the classic "lights go off but CPU fan keeps running"). Also when using VoodooPower (and DSDT.aml with no SSDT data) I don't get the CST evaluation error messages on boot.

I have used VoodooPower in the past (thanks Superhai) and I think that it injects data to prevent errors, and to make it work. Superhai?

 

p.s. I see (uphuck) that you changed some device names in your DSDT (for the uninformed: to match a Mac):

 

PIC -> IPIC

DMAD > DMAC

TMR -> TIMR

RTC0 -> RTC

COPR -> MATH

OMSC -> LDRC

[yonika]

I think that I already explained that in post #118

 

 

1) You'll either have to use the P-State Calculator (link in post #1) or use a calculator.

2) You MB/BIOS supports C1/C2 and C3 (check the latency in the FACP) so you don't need it.

3) The power should drop to either1.000 or 0.500 in CPU-i.

4) Probably that CST is natively supported, but there's no documentation about this value.

5) You can check it with pmset -g | grep hibernatemode and change it with sudo pmset -a hibernatemode n* or use the Deep Sleep Widget.

6) This appears to be something that lowers the temperature a little, but I don't know, yet, what it really does or is used for.

 

*Here are the values (from deepsleep.pdf) and the meaning of it:

 

• 0 (quick): Default sleep behavior on most Apple computers. RAM is still powered on while sleeping. Wake up is fast. Safe sleep is disabled.

• 1 (deep): Hibernation behavior. System is totally shut down while sleeping. RAM contents are dumped to disk. Wake up is slow.

• 3 (safe): Default behavior on Powerbook HD and later computers. RAM is still powered on while sleeping. Wake up is fast. Safe sleep is enabled, so RAM contents are also dumped to disk before going to sleep.

• 5 (deep): Same as mode 1 for systems with encrypted virtual memory.

• 7 (safe): Same as mode 3 for systems with encrypted virtual memory.

 

I have not found any information about CSTInfo as of yet i.e. I don't know exactly what it does.

 

 

I have used VoodooPower in the past (thanks Superhai) and I think that it injects data to prevent errors, and to make it work. Superhai?

 

Hey, thanks for replying,

 

I still don't understand somethings though,

 

About p-states calculator ? All it does is convert from specific values I set to hex values for the PSS table,

How do i know what power in [mW] or voltages to enter in the first place ? multiplier and speed is easy, though I'm not sure if there are more than just 6,7,8,9 ?

 

About c-states in cpu-i ? where do i see that ? I can see only speed, multiplier and voltage, am I missing a column ?

 

About deep sleep ? I tried Smartsleep prefPane (deep sleep widget has a bug in SL) which sets these values of hibernation mode, then I put my hackintosh to sleep, before sleep it gave me the gray screen of deep sleep, and went to sleep, but when I powered it up, it just booted normally, not from the sleep image, then I checked and saw that there was a saved sleep image on disk, I don't understand, how does Chameleon (I'm using RC1) knows if there is a sleep image or not ? and how to boot ? or maybe OS X needs to tell the bios it is not a regular boot ?

 

Sorry for all these question on questions, and thank you for taking the time and patience to answer, It's just that it always looks close to solving these issues and something else comes up but now it feels like it's getting somewhere

 

Thanks again,

Jonathan