Jump to content

DSDT - Vanilla Speedstep - Generic Scope (_PR)


  • Please log in to reply
1945 replies to this topic

#61
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

Are c-states processor dependent? Since I didn't have c-state tables on my mobo, I just borrowed from this thread. The more I think about it, my audio stutter could have been because I was rapidly dropping in and out of a c-state. If I did a bit more activity like moving the mouse a lot, the audio stopped stuttering. So the heuristics as when to idle or not were wrong for me, i.e playing audio was just at the threshold of when to drop into a c-state (perhaps even just C0) and the latency switch back and forth accounted for the stutter.


It's unlikely you'll enter a c-state when playing video/audio. But could be a latency problem.

More likely a latency problem with p-states. Can you see if you are flip-flopping between p-states when you have audio stutter?

D.

#62
hackcat

hackcat

    InsanelyMac Protégé

  • Members
  • PipPip
  • 62 posts
Just playing audio cpu-i shows me pretty much pegged at the lowest p-state x6. I only get the stutter issue by adding c-states to my dsdt.

I finally added my p-states without appending ssdt tables to the dsdt. I defined my p-states at the beginning of the dsdt. Doing so, you also only have the 0x0A latency value defined.

When I had the ssdt tables appended, the NPSS had the 0xA0 and the SPSS had the 0x0A values for transition latency. Suggesting my stutter could be fixed there?

#63
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

Just playing audio cpu-i shows me pretty much pegged at the lowest p-state x6. I only get the stutter issue by adding c-states to my dsdt.

I finally added my p-states without appending ssdt tables to the dsdt. I defined my p-states at the beginning of the dsdt. Doing so, you also only have the 0x0A latency value defined.

When I had the ssdt tables appended, the NPSS had the 0xA0 and the SPSS had the 0x0A values for transition latency. Suggesting my stutter could be fixed there?


Can you post your SPSS and NPSS tables

D.

#64
hackcat

hackcat

    InsanelyMac Protégé

  • Members
  • PipPip
  • 62 posts
Using your appended ssdt tables with borrowed c-states, I just changed the following:
[codebox]
Name (SPSS, Package (0x03)
{
Package (0x06)
{
0x0C80,
0x0135BA,
0xA0,
0x0A,
0x082A,
0x082A
},

Package (0x06)
{
0x0AF0,
0x01025F,
0xA0,
0x0A,
0x0726,
0x0726
},

Package (0x06)
{
0x0960,
0x00CD35,
0xA0,
0x0A,
0x0620,
0x0620
}
})
Name (NPSS, Package (0x03)
{
Package (0x06)
{
0x0C80,
0x0135BA,
0x0A,
0x0A,
0x082A,
0x082A
},

Package (0x06)
{
0x0AF0,
0x01025F,
0x0A,
0x0A,
0x0726,
0x0726
},

Package (0x06)
{
0x0960,
0x00CD35,
0x0A,
0x0A,
0x0620,
0x0620
}
})[/codebox]

Those p-states work for me when I put them upfront in the dsdt without appending ssdt tables:
[codebox]
Processor (CPU0, 0x00, 0x00000410, 0x06)
{
Name (_PPC, Zero)
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000199, // Address
,)
},

ResourceTemplate ()
{
Register (FFixedHW,
0x10, // Bit Width
0x00, // Bit Offset
0x0000000000000198, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0C80,
0x0135BA,
0x0A,
0x0A,
0x082A,
0x082A
},

Package (0x06)
{
0x0AF0,
0x01025F,
0x0A,
0x0A,
0x0726,
0x0726
},

Package (0x06)
{
0x0960,
0x00CD35,
0x0A,
0x0A,
0x0620,
0x0620
}
})
}[/codebox]
BTW, using an overclocked e6750 which only has 3 p-states. x8 is 3200 @ 1.372v, x7 2800 @ 1.308v, x6 2400 @1.212v

#65
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male
Weird. It seems that I don't need to modify anything to get P-States working with Leopard. Snow Leopard however is a different cat, but that is about to change.

Edit: I got it working with Snow Leopard. All I had to do was to change "MacPro3,1" in:
/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/info.plist
into "P5K PRO" – because that is what System Profiler shows for this configuration – and that was it.

I wonder if there's any bit of code in CPU-i to show C-States, because how else would I know if that works? Checking...

#66
SA22C

SA22C

    Escaping the Reality Distortion Field

  • Members
  • PipPipPipPipPip
  • 333 posts
  • Gender:Male
  • Location:Soviet Kanukistan

Weird. It seem that I don't need to modify anything to get P-States working with Leopard. Snow Leopard however is a different cat, but that is about to change.

Edit: I got it working with Snow Leopard. All I had to do was to change "MacPro3,1" in:
/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/info.plist
into "P5K PRO" – because that is what System Profiler shows for this configuration – and that was it.

I wonder if there's any bit of code in CPU-i to show C-States, because how else would I know if that works? Checking...


I nabbed the OP's tables and changed the p-states to match my CPU. I don't get the C-state error anymore on boot and my Hack now sleeps and shuts down normally. However, I see no evidence that the CPU is actually stepping. The frequency seems pegged at the max. I am unable to boot into 32-bit (I have no idea why, but I the GUI refuses to load in x32) so I can't use CPUi to test, but a sysctl -a | grep freq returns a current, min and max freq as the same value, leading me to believe that no stepping is taking place.

I was also curious about the difference between the NPSS and SPSS states. What do I need to do differently between those two?

Thanks.

System is as follows:

Asus P5K-E
Intel Core 2 Duo E6400
Bios version 1305

My system supplies no SSDT tables of any kind, so I hacked in the provided SSDT dump in the OP.

#67
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU
I'm getting the following in IOregexplorer...

You can see that the Pstates are read in but not active? GPU is active though. And looks like the cstates aren't active either.

This DSDT was working under 10.5.7 nicely, but SL 10A432 seems a different beastie. My _CST items are from the MacPro3,1 but if I change my smbios.plist to refer to this and also the ACPI_SMC_PlatformPlugin to reference that GPU scaling turns off... smbios.plist is now set to a MacBookPro5,1 which enables the GPU scaling.

Does anyone have the _CST from the MBP5,1 handy at all? I cannot seem to find it in any of the MBP5,1 SSDT dumps around the place.

Some screenshots.

Attached File  Screen_shot_2009_09_08_at_1.55.49_PM.png   232.08KB   298 downloads

Attached File  Screen_shot_2009_09_08_at_1.56.06_PM.png   71.44KB   212 downloads

Attached File  Screen_shot_2009_09_08_at_1.56.36_PM.png   26.61KB   151 downloads

And still getting the C-states error:

AppleACPICPU: ProcessorId=0 LocalApicId=0 Enabled
AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled
ACPI: System State [S0 S3 S4 S5] (S3)
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

Cheers,

Brett

PS this is fun in a sick kind of way :D Seeing what differences are made.

#68
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

...And still getting the C-states error:

ACPI: System State [S0 S3 S4 S5] (S3)
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

No error here. You probably just forgot something (no offense). Feel free to attach your vanilla dsdt.dsl and the modified one.

#69
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU

No error here. You probably just forgot something (no offense). Feel free to attach your vanilla dsdt.dsl and the modified one.



Hahaha, no offence at all, I'm new to DSDT / SSDT so happy to take pointers from people with more experience. I will attach them a bit later this evening. Thanks in advance for having a look!

Brett

Attached:

1. acpi_dsdt.dsl is the OE extracted from Everest.
Attached File  acpi_dsdt.dsl.zip   15.18KB   28 downloads
2. DSDT-T9300.dsl is modified with _PSS for the T9300 and the other fixes for my Dell.
Attached File  DSDT_T9300.dsl.zip   17.02KB   50 downloads

Thanks!

#70
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

I nabbed the OP's tables and changed the p-states to match my CPU. I don't get the C-state error anymore on boot and my Hack now sleeps and shuts down normally. However, I see no evidence that the CPU is actually stepping. The frequency seems pegged at the max. I am unable to boot into 32-bit (I have no idea why, but I the GUI refuses to load in x32) so I can't use CPUi to test, but a sysctl -a | grep freq returns a current, min and max freq as the same value, leading me to believe that no stepping is taking place.

I was also curious about the difference between the NPSS and SPSS states. What do I need to do differently between those two?

Thanks.

System is as follows:

Asus P5K-E
Intel Core 2 Duo E6400
Bios version 1305

My system supplies no SSDT tables of any kind, so I hacked in the provided SSDT dump in the OP.


Hi SA22C

I presume you've tried extracting SSDT in Linux? Some SSDT seem to be blocked when extracted in OS X.

Also p-states can also be added under the scope (_PR) part of DSDT rather than appending SSDT (if you can't find any SSDT then this is probably more suitable than using borrowed SSDT.)

See this example curt' mitch_de
Scope (_PR){Processor (CPU0, 0x00, 0x00000410, 0x06){Name (_PPC, 0x00)Name (_PCT, Package (0x02){ResourceTemplate (){Register (FFixedHW, // PERF_CTL0x10, // Bit Width0x00, // Bit Offset0x0000000000000199, // Address,)},ResourceTemplate (){Register (FFixedHW, // PERF_STATUS0x10, // Bit Width0x00, // Bit Offset0x0000000000000198, // Address,)}})Name (_PSS, Package (0x04) // 4 Pstates 6-9 fsb muilt * 333 FSB, E7300-2660 GHZ-266*10{/* multi 10 OFF Package (0x06) { 3330, 93816, 10, 10, 0xA25, 0xA25 } */Package (0x06) { 2997, 80535, 10, 10, 0x921, 0x921 }, // 2997 MHZ = 9* 333Package (0x06) { 2664, 68120, 10, 10, 0x81D, 0x81D },Package (0x06) { 2331, 56571, 10, 10, 0x71A, 0x71A },Package (0x06) { 1998, 45889, 10, 10, 0x616, 0x616 }})} // end CPU0Processor (CPU1, 0x01, 0x00000410, 0x06){Name (_PPC, 0x00)Name (_PCT, Package (0x02){ResourceTemplate (){Register (FFixedHW, // PERF_CTL0x10, // Bit Width0x00, // Bit Offset0x0000000000000199, // Address,)},ResourceTemplate (){Register (FFixedHW, // PERF_STATUS0x10, // Bit Width0x00, // Bit Offset0x0000000000000198, // Address,)}})Name (_PSS, Package (0x04) // 4 Pstates 6-9 fsb muilt{/* multi 10 OFF Package (0x06) { 3330, 93816, 10, 10, 0xA25, 0xA25 } */Package (0x06) { 2997, 80535, 10, 10, 0x921, 0x921 }, // 2997 MHZ = 9* 333Package (0x06) { 2664, 68120, 10, 10, 0x81D, 0x81D },Package (0x06) { 2331, 56571, 10, 10, 0x71A, 0x71A },Package (0x06) { 1998, 45889, 10, 10, 0x616, 0x616 }})} // end CPU1Processor (CPU2, 0x02, 0x00000410, 0x06){} // end CPU2Processor (CPU3, 0x03, 0x00000410, 0x06){} // end CPU3}

When I get some time I'm going to try to add c-state (_cst) table in this fashion. See post #53 and page 281 section 8.4.2 of ACPI specs. This could be a more universal method?!

D.

#71
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Hahaha, no offence at all, I'm new to DSDT / SSDT so happy to take pointers from people with more experience. I will attach them a bit later this evening. Thanks in advance for having a look!

Hi Brett,

I looked at your files and immediately noticed something, which I expected to be honest. The problem is that you copied stuff, but it is not initialized. Not at all. Let's have a look at this:
Scope (\)	{		Name (SSDT, Package (0x0C)		{			"CPU0IST ", 			0xDFE72CB4, 			0x02C8, 			"CPU1IST ", 			0xDFE72F7C, 			0xC4, 			"CPU0CST ", 			0xDFE7264A, 			0x05E5, 			"CPU1CST ", 			0xDFE72C2F, 			0x85		})		Name (CFGD, 0x013369F7)		Name (PDC0, 0x80000000)		Name (PDC1, 0x80000000)		Name (SDTL, 0x00)	}
N.b. You don't need SSDT to get P-States working – I did not include it and everything appears to be working, and without the usual startup error yes.

Edit: I don't need SSDT because my DSDT declares it like this:
Processor (CPU1, 0x01, 0x00000810, 0x06)
		{
			OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)
Which is basically the same, but quicker.

Now have a look at PDC[0/1] because like I said, nowhere in your DSDT can I find anything that initializes these two, representing the capabilities so they are pretty important. This usually is the task of the OSPM capabilities interfaces called Processor Driver Capabilities and/or Operating System Capabilities - depending on the used ACPI version. But your DSDT doesn't include them! In other words; you either need to add _PDC(){} and/or _OSC(){} to get the job done, or init the PDCn yourself with the help of the attached table (key to get C-States going).

Edit: I just had another quick look at this snippet (from FormerlyKnownAs et all):
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))			{				If (LEqual (And (PDC0, 0x0A), 0x0A))				{					If (And (CFGD, 0x02))					{						OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02							)))						Load (IST0, HI0)					}					Store (One, TLD0)				}			}		}	}
Now note this:
CreateDWordField (Arg0, 0x08, CAP0)
			Store (CAP0, PDC0)
Which tells me that Apple is only using/checking the revision ID, which for your info is the first argument (Arg0). That is if this snippet is really taken from a real Mac (Edit: Not, see next post).

And here's the table I mentioned earlier:

Attached Files



#72
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

Which tells me that Apple is only using/checking the revision ID, which for your info is the first argument (Arg0). That is if this snippet is really taken from a real Mac.


Hi Master Chief

That is an SSDT IST table - as extracted from my Gigabyte MB. It's not Apple.

D.

#73
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Hi Master Chief

That is an SSDT IST table - as extracted from my Gigabyte MB. It's not Apple.

D.

Me ducks. I should have noticed it as it was right in my face. Thing is; I just got my morning shower - still waiting for my cappuccino after breakfast - and thus things should go better in a few minutes. Ah lovely there it is.

p.s. Any real Mac DSDT's floating around here? Got it. This should help – post #7 for the SSDT tables ;)

Update: My _PDC() {} and OSC() {} ASL code is almost the same as the MacPro3,1 but mine doesn't Load() the CST table.

#74
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU
Thanks for the pointers. I'll run through the SSDT from the MBP5,1 I have and compare them to mine for the OST and PDC fields.

The following lines from yours:

Processor (CPU1, 0x01, 0x00000810, 0x06)
{
OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

What memory addresses are they referring to from your SSDT tables? The CST or IST?

I did put in my own PDC and OST but that made no difference (been playing with wireless routers all day and this is the first sit down I've had). As mentioned I'll look through the SSDT-1 from an MBP5,1 and see what they are doing to load the CST and IST from SSDT...

OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08)))

(for CPU0 from mine).

Actually those are identical, and IST0 is loaded to HI0 and CST0 to HC0...

Code snippet -> from _OST for the Dell
[codebox] If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)),
LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3)))))
{
Store (0x06, STS0)
Return (Arg3)
}

If (LNotEqual (Arg1, 0x01))
{
Store (0x0A, STS0)
Return (Arg3)
}

Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0)[/codebox]

For the MBP5,1
[codebox] If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)),
LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3)))))
{
Store (0x06, Index (STS0, 0x00))
Return (Arg3)
}

If (LNotEqual (Arg1, 0x01))
{
Store (0x0A, Index (STS0, 0x00))
Return (Arg3)
}

Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0)[/codebox]

Just the way the Store is done is different between the two SSDT's... Not sure if that is significant at all or not, thoughts?

Thanks,

Brett

#75
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

Thanks for the pointers. I'll run through the SSDT from the MBP5,1 I have and compare them to mine for the OST and PDC fields.

The following lines from yours:

Processor (CPU1, 0x01, 0x00000810, 0x06)
{
OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

What memory addresses are they referring to from your SSDT tables? The CST or IST?

I did put in my own PDC and OST but that made no difference (been playing with wireless routers all day and this is the first sit down I've had). As mentioned I'll look through the SSDT-1 from an MBP5,1 and see what they are doing to load the CST and IST from SSDT...

OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08)))

(for CPU0 from mine).

Actually those are identical, and IST0 is loaded to HI0 and CST0 to HC0...


Just the way the Store is done is different between the two SSDT's... Not sure if that is significant at all or not, thoughts?

Thanks,

Brett


Hi Guys

Please see post 71 here in ab__73's bootloader thread - regarding finding correct memory addresses for _cst. It involves some messing around with voodoo kernel but c-states wont load unless this is correct.

D.

#76
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU

Hi Guys

Please see post 71 here in ab__73's bootloader thread - regarding finding correct memory addresses for _cst. It involves some messing around with voodoo kernel but c-states wont load unless this is correct.

D.


Are you still injecting via DSDT.aml or are you using mutliple SSDT.aml files?

Next question, has anyone seen a voodoo kernel for SL? Otherwise I'll have to resurrect my 10.5.7 installation ;)

Cheers
Brett

#77
FKA

FKA

    are we there yet?

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,626 posts
  • Gender:Male

Are you still injecting via DSDT.aml or are you using mutliple SSDT.aml files?

Next question, has anyone seen a voodoo kernel for SL? Otherwise I'll have to resurrect my 10.5.7 installation :)

Cheers
Brett


too busy with work, haven't had any time to play around with this recently so sill using SSDT appended to DSDT.

D.

#78
goodbye losers

goodbye losers

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 261 posts
hi,

my specs

snow leopard Chameleon-2.0-r431+10.1 bootloader
ga-965p-dq6
c2d 6700@2660MHz

i have a boot error - kernel ACPI_SMC_PlatformPlugin:PushCPU_CSTData - _CST evaluation failed. my problem is native speedstep...please can you look inside my dsdt.aml for options like speedstep?

#79
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Thanks for the pointers. I'll run through the SSDT from the MBP5,1 I have and compare them to mine for the OST and PDC fields.

The following lines from yours:

Processor (CPU1, 0x01, 0x00000810, 0x06)
{
OperationRegion (STBL, SystemMemory, 0xCFF8E0D0, 0x01D2)

What memory addresses are they referring to from your SSDT tables? The CST or IST?

In this case it is referring to my computers IST table, but OperationRegion can be used for anything, including yours below, but there is no need to replace them.

I did put in my own PDC and OST but that made no difference (been playing with wireless routers all day and this is the first sit down I've had). As mentioned I'll look through the SSDT-1 from an MBP5,1 and see what they are doing to load the CST and IST from SSDT...

OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08)))

(for CPU0 from mine).

Actually those are identical, and IST0 is loaded to HI0 and CST0 to HC0...

The second argument in a Load() statement is a handle (see ACPI programmers manual) which can be used to release the table. Actually, you can see that yourself by reading the second argument like this: HI0 refers to Handle IST 0 and HC0 refers to Handle CAP 0

Code snippet -> from _OST for the Dell
Store (0x06, STS0)
Store (0x0A, STS0)

For the MBP5,1

Store (0x06, Index (STS0, 0x00))
Store (0x0A, Index (STS0, 0x00))

Just the way the Store is done is different between the two SSDT's... Not sure if that is significant at all or not, thoughts?

Yes, that is different. The first call simply replaced STS0 with 0x06 while the second call replaces only the nth argument – in this case 0 – with 0x06/0x0a.

p.s. If you do happen to have SSDT tables, then by all means use that and don't go looking for anything else. Assuming that you don't have to change anything in it of course :D

And like I said before, that table is your key to success. Here's an example:

To anyone wondering about why there are two tables in _PSS, one called SPSS and the other NPSS; Take a look at this example:
Method (_PSS, 0, NotSerialized)
		{
			If (LEqual (And (TYPE, 0x01), 0x01)) 
			{
				Return (NPSS)
			}
			Else
			{
				Return (SPSS)
			}
		}
Now check the table I proved to in post #71 to find this: If set, the OSPM supports the C1 "I/O then Halt" FFH sequence for multi-processor configurations. And you'll find other use of it throughout the DSDT/SSDT.

n.b. TYPE in this example is probably called differently in yours, like PDC0 for example.

You should see a similar check in method _PCT() in your SSDT – which is one of the three Performance Control objects (_PCT, _PSS and _PPC) – to differentiate between FFixedHW and SystemIO et all.

#80
Beerkex'd

Beerkex'd

    Content Provider

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 3,000 posts
  • Gender:Male
  • Location:Belo Horizonte - Brazil
Just attaching my ACPI dump for reference. It was dumped with Lavalys Everest under Windows, and seems to be complete. The FACP is there too.

This could be interesting for anyone using a Core 2 Duo E8500 who has difficulties getting a complete dump.

I only just started looking at it, haven't tried doing anything with it yet.
Attached File  P5QE_C2D8500_ACPIDUMP.zip   22.52KB   48 downloads
Of course if someone wants to take a look and help me get speedstepping working I wouldn't mind ;)
Here's my current DSDT.
(removed)

/EDIT 09-12
Both archives updated.

/EDIT 09-19
Old attached DSDT removed - and we have liftoff - see this post:
http://www.insanelym...p...t&p=1272462





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy