1945 replies to this topic

[Master Chief]

FormerlyKnownAs, on Sep 11 2009, 02:50 AM, said:

Here's DSDT with C1, 2 and 3 for my MB that does not support C-states
...

Current conclusion - If it is possible to fix ACPI for MB that do not support C-states, I'm not smart enough to do it!

Huh?  I am confused.  You mean that this CST object �" the one in the attachment file �" wasn't obtained from your BIOS?   Or are you saying that it doesn't work for you?  Anyway.  Let's just have a look at some part of your dsdt.dsl:

	Scope (_PR.CPU0)
	{
		Name (HI0, Zero)
		Name (HC0, Zero)
		Name (TLD0, Zero)
		Method (_PDC, 1, NotSerialized)
		{
			CreateDWordField (Arg0, 0x08, CAP0)
			Store (CAP0, PDC0)
			If (LEqual (TLD0, Zero)) // Is TLD0 Zero?  Which is true.
			{
				If (LEqual (And (PDC0, 0x0A), 0x0A)) // Is bit 2 of PDC0 set?  Which must be true, or it won't load the IST table.
				{
					If (And (CFGD, 0x02)) // Is bit 1 of CFGD set?  Which is true for the provided value of 0x04030302.
					{
						// Point IST0 to the provided memory area
						OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02
							)))
						Load (IST0, HI0) // Load the IST0 table �" HI0 is a handle which can be used to unload the table.
					}

					Store (One, TLD0) // Preserve state information across S1-S3 sleep.
				}
			}
		}
	}

And in particular the following snippet, which is part of all but the first PDC object:

			  
 If (And (CFGD, 0x10)) // Is bit 4 of CFGD set? Which is NOT true for the provided value of 0x04030302.
 {
   OperationRegion (CSTn, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B)))
   Load (CSTn, HC1) // Load the CSTn table.
 }

This code is responsible for loading the CST tables, on MB's with CST tables that is.  Now note the CFGD value in your DSDT, which is 0x4030302.  Got it?  Yes, that bit is not set.  You might want to change it to 0x4030312 and remove the CST object from your DSDT.  That should (also) work, or at least make it the same

Note that the PDC object is evaluated only once, and prior to evaluation of any other processor power management objects returning configuration information.  And PDC objects are normally called with three arguments, being: RevisionID, Count and CapabilitiesDWORD1.  However, not in your case it seems.  Time for me to change my PDC object to see what I am getting

[FKA]

Master Chief, on Sep 11 2009, 05:39 AM, said:

Huh?  I am confused.  You mean that this CST object �" the one in the attachment file �" wasn't obtained from your BIOS?   Or are you saying that it doesn't work for you?  Anyway.  Let's just have a look at some part of your dsdt.dsl:

This code is responsible for loading the CST tables, on MB's with CST tables that is.  Now note the CFGD value in your DSDT, which is 0x4030312.  Got it?  Yes, that bit is not set.  You might want to change it to 0x4030312 and remove the CST object from your DSDT.  That should (also) work, or at least make it the same

Note that the PDC object is evaluated only once, and prior to evaluation of any other processor power management objects returning configuration information.  And PDC objects are normally called with three arguments, being: RevisionID, Count and CapabilitiesDWORD1.  However, not in your case it seems.  Time for me to change my PDC object to see what I am getting

I've tried changing CFGD value to 0x4030312 and I still dont see any cst loaded in dmesg.
In fact if you look at previous output from dmesg there is no ist loaded either???? OR in fact any SSDT !!

ACPI: RSDP @ 0xc6b000/0x0014 (v000 GBT   )
ACPI: RSDT @ 0xc6c000/0x0034 (v001 GBT	GBTUACPI 0x42302E31 GBTU 0x01010101)
ACPI: FACP @ 0xc6d000/0x0074 (v001 GBT	GBTUACPI 0x42302E31 GBTU 0x01010101)
ACPI: DSDT @ 0xc65000/0x50EC (v001 GBT	GBTUACPI 0x00001000 INTL 0x20080926)
ACPI: FACS @ 0xdfee0000/0x0040
ACPI: HPET @ 0xdfee7e00/0x0038 (v001 GBT	GBTUACPI 0x42302E31 GBTU 0x00000098)
ACPI: MCFG @ 0xdfee7e80/0x003C (v001 GBT	GBTUACPI 0x42302E31 GBTU 0x01010101)
ACPI: APIC @ 0xdfee7d00/0x0084 (v001 GBT	GBTUACPI 0x42302E31 GBTU 0x01010101)

And yes I have no cst table and have borrowed from, initially MacPro3,1 and now from HP530 but have edited C-state values to suit my latency requirements.

I'm stepping away from this for a week or so. Be interesting to see where you get to. I'm still sceptical that it is possible to achive c-state support if it is not native to your MB.

Enjoy
D.

**EDIT** please not with DSDT11-09-09.dsl (post No.120) and with CFGD value set to 0x4030312,  my p-states are still working and I still don't have any cst evaluation errors !!

[Master Chief]

FormerlyKnownAs, on Sep 11 2009, 02:49 PM, said:

I've tried changing CFGD value to 0x4030312 and I still dont see any cst loaded in dmesg.
In fact if you look at previous output from dmesg there is no ist loaded either???? OR in fact any SSDT!!

Dave,

I would say because of this: "PDC objects are normally called with three arguments, being: RevisionID, Count and CapabilitiesDWORD1."   I mean, just have a look at the original MacPro3,1 files and note the three arguments there.  Not to mention the missing OSC objects in your DSDT.

FormerlyKnownAs, on Sep 11 2009, 02:49 PM, said:

**EDIT** please not with DSDT11-09-09.dsl (post No.120) and with CFGD value set to 0x4030312,  my p-states are still working and I still don't have any cst evaluation errors !!

I wonder if it still works when you restore the original kext – the one without any modifications – and/or remove the (calls to) PSS object in your DSDT.  If that still works... then it must be the native Intel SpeedStep Technology kicking in.

[SA22C]

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.

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

[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

[yonika]

yonika, on Sep 11 2009, 09:27 PM, said:

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]

SA22C, on Sep 11 2009, 06:14 PM, said:

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?

SA22C, on Sep 11 2009, 06:14 PM, said:

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]

Master Chief, on Sep 12 2009, 11:35 AM, said:

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]

SA22C, on Sep 12 2009, 07:59 PM, said:

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).

SA22C, on Sep 12 2009, 07:59 PM, said:

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]

yonika, on Sep 12 2009, 10:34 AM, said:

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]

Master Chief, on Sep 12 2009, 09:25 PM, said:

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]

Superhai, on Sep 12 2009, 10:02 PM, said:

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]

Master Chief, on Sep 12 2009, 10:14 PM, said:

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]

Master Chief, on Sep 12 2009, 05:55 PM, said:

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]

yonika, on Sep 13 2009, 12:05 AM, said:

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.

Superhai, on Sep 12 2009, 10:37 PM, said:

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   31.71K   8 downloads

My ACPI dumps and a dsdt.dsl without the SSDT stuff (including FACP) is here:
http://www.insanelym...p...t&p=1258828

[Master Chief]

Beerkex'd, on Sep 13 2009, 06:57 AM, said:

...

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]

Master Chief, on Sep 12 2009, 09:23 PM, said:

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

Attached Files

•  DSDT_files.zip   58.39K   20 downloads
•  SSDT_files.zip   6.73K   17 downloads

[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..

Master Chief, on Sep 13 2009, 03:11 AM, said:

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?