DSDT - Vanilla Speedstep - Generic Scope (_PR)

[Master Chief]

@Master Chief:

ok. after removing all the ssdt tables from the dsdt and booting normally with chameleon, i have just 2 ssdt tables in the ACPI (checked with IORegExplorer). four tables are missing and they are the IST and CST tables for CPU0 and CPU1.

Just to be absolutely sure that I understand you; The ACPI Tables show more tables when you add the extra objects to your DSDT? Right?

 

so as per your advise i am trying to change to the CFGD value and booting and checking whether the tables get loaded. But i need some help here to understand the process.

 

an excerpt from my ssdt which gets loaded: (this is the code to load one of the missing 4 tables. the missing tables have the cst method in them)

 

			If (And (CFGD, One))
		  {
			  If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 
				  0x09), 0x09)), LNot (And (SDTL, One))))
			  {
				  Or (SDTL, One, SDTL)
				  OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02
					  )))
				  Load (IST0, HI0)
			  }
		  }

now my CFGD value is 0x053969F1 and you suggested i start trying with 0x01000131. assuming that the PDC and SDTL conditions are working, the statement within the "if" clause should get loaded with any one of the CFGD values above. but ofcourse it does not, because the IST table is not loaded. do you have any idea why? or do you need more information? i have dumped the data at the address locations referenced in that locations and they are indeed correct. so it is not a "hardcoded table missing" problem.

The main question for now is if you have all tables when you add the _CST object to your Processor declarations. If that is the case, then we're on to something.

 

Like I said in post #186 I don't see any tables (anymore) so I am full at it. I started to re-read specific parts of the ACPI specification to see if it should work as I think is should, and I think I am right. Let's have a look at that Load() statement which reads:

 

"The Object parameter can either refer to an operation region field or an operation region directly. If the object is an operation region, the operation region must be in SystemMemory space. The Definition Block should contain an ACPI DESCRIPTION_HEADER of type SSDT. The Definition Block must be totally contained within the supplied operation region or operation region field. OSPM reads this table into memory, the checksum is verified, and then it is loaded into the ACPI namespace. The DDBHandle parameter is the handle to the Definition Block that can be used to unload the Definition Block at a future time."

 

The red parts here are the most interesting parts, especially the second one. The rest should not really be a problem. And when you do have more ACPI tables with the extra bits – which I hope, but it is almost too good to be true – then we should be able to get it working. There is however still a lot more reading to be done, on my side, which I intend to do right now... and after that right back to hacking.

 

Update: I installed the SSDT boot file on Leopard which loads /SSDT-n.aml but non of them showed up in the ACPI Tables.

[yeehaa]

Just to absolutely sure that I understand you; The ACPI Tables show more tables when you add the extra objects to your DSDT? Right?

 

no. i added all my ssdt tables to dsdt and did a dropssdt. then the CSTInfo started showing up in IORegExplorer. (this is true even with no dropssdt. but then also, the last 4 ssdt tables do not get loaded)

 

Explanation:

All SSDT tables added to DSDT and boot with DropSSDT: CSTInfo in IORegexp, no CST error messages and no SSDT tables ( )

All SSDT tables added to DSDT and boot normally: CSTInfo in IORegexp, no CST error messages and just 2 SSDT tables instead of total 6.

DSDT with just CST method and normal boot: No CSTInfo in IORegEXp, CST error messages during boot, 2 SSDT tables instead of 6.

all of this brings me back to my original question. why is that load statement i quoted in my last message not loading?! am stumped.

 

The main question, for now, is if you have all tables when you add the _CST object to your Processor declarations. If that is the case, then we're on to something.

 

Unfortunately this is not the case!

 

Like I said in post #186 I don't see any tables (anymore) so I am full at it. I started to re-read specific parts of the ACPI specifications to see if it should work as I think is should, and I think I am right. Let's have a look at that Load() statement which reads:

 

"The Object parameter can either refer to an operation region field or an operation region directly. If the object is an operation region, the operation region must be in SystemMemory space. The Definition Block should contain an ACPI DESCRIPTION_HEADER of type SSDT. The Definition Block must be totally contained within the supplied operation region or operation region field. OSPM reads this table into memory, the checksum is verified, and then it is loaded into the ACPI namespace. The DDBHandle parameter is the handle to the Definition Block that can be used to unload the Definition Block at a future time."

 

The red parts here are the most interesting parts, especially the second one. The rest should not really be a problem. And when you do have more ACPI tables with the extra bits �" which I hope, but it is almost too good to be true �" then we should be able to get it working. There is however still a lot more reading to be done, on my side, which I intend to do right now... and after that right back to hacking.

 

Update: I installed the SSDT boot file on Leopard wich loads /SSDT-n.aml but non of them showed up in the ACPI Tables.

 

i cannot test this because am on Snow and do not have a leopard installation.

[Master Chief]

no. i added all my ssdt tables to dsdt and did a dropssdt. then the CSTInfo started showing up in IORegExplorer. (this is true even with no dropssdt. but then also, the last 4 ssdt tables do not get loaded)

 

Explanation:

All SSDT tables added to DSDT and boot with DropSSDT: CSTInfo in IORegexp, no CST error messages and no SSDT tables ( )

All SSDT tables added to DSDT and boot normally: CSTInfo in IORegexp, no CST error messages and just 2 SSDT tables instead of total 6.

DSDT with just CST method and normal boot: No CSTInfo in IORegEXp, CST error messages during boot, 2 SSDT tables instead of 6.

all of this brings me back to my original question. why is that load statement i quoted in my last message not loading?! am stumped.

At least you got two tables loaded. And knowing what tables they are might be helpful – you can check this by copying the tables into a hex editor and then decompile them, or by comparing the values in IORegistryExplorer.

[Squirrelf]

About the heat problem I had:

 

well I didn't know about appleLPC until I decided to read through the thread

using that kext (by adding 3a16 to it) makes my startup much faster (compared to when it's not loaded), my temperature are much cooler

I used MP3.1 c-states and my linux dump ssdt, I didn't change the kext in S/L/E where we are supposed to set to MP3.1 if we use MP3.1 c-states, it didn't matter, it is the way it was,( which is MP4.1)

and p-states and c-states are definitely working very well

 

for EP45-UD3R, or any board using ICH10R 3a16

I want a vanilla system, so I made a legacy appleLPC kext (it's the first one I made so if you know about how to make legacy kext don't hesitate to double check the plist and let me know) , anyway it's loading and working the way I made it (you know that it is loaded when the "Start up automatically... " option appear in the energy saver,[)

Edit: sleep does not work with it for me when dsdt has c-states, without it sleep works, but temperature is higher...

AppleLPC for ICH10R 3a16 (runs from extra/extensions):

LegacyAppleLPC.kext.zip

 

Enjoy

[yeehaa]

At least you got two tables loaded. And knowing what tables they are might be helpful �" you can check this by copying the tables into a hex editor and then decompile them, or by comparing the values in IORegistryExplorer.

 

I know what all are not loading! I have a total of 6 SSDT tables. SataAhci, CpuPm, Cpu0Ist, Cpu0Cst, ApIst (or CPU1Ist), ApCst (or CPU1Cst). Of these SataAhci and CpuPm tables load just fine.

[Master Chief]

I know what all are not loading! I have a total of 6 SSDT tables. SataAhci, CpuPm, Cpu0Ist, Cpu0Cst, ApIst (or CPU1Ist), ApCst (or CPU1Cst). Of these SataAhci and CpuPm tables load just fine.

Yeah. That was to be expected. Now we need to figure out a way of loading it, but what is preventing it from loading? And I have no idea.

 

Also, I won't have time to help anyone, not until I figured out how to change the device-id of my network card (tips via PM are welcome). Sorry folks

[thestevo]

Hello, I originally got P-states registered by following this guide but I haven't been able to get them working. I also get CST errors. I talked with Brett Whinnen, and made some modifications on his advice, but that did not end up changing things. I've got 17 P-states showing up in CPU-i, but the status always shows the same for both cores: 796 MHz, 8x multiplier, and 1.004 voltage. Interestingly enough though, that is not one of the P-states. The closest P-state listed is supposed to have 1.116 V.

 

For now I'd be happy just to get my P-states working, I suspect my C-state problem is the same as Brett's since we both have a Dell with a T9300. Does anyone have any suggestions?

dsdt.aml.zip

[keeza]

Need some help please to get my speedstepping working.

 

Please see my attached C-States which I created.

 

I've compiled my DSDT with the SSDT and no errors.

 

I've deleted Disabler kext from E/E

 

CPU-i shows my temps at idle have gone up (55-58 degrees) and no stepping or changes show under the P-States tab of CPU-i.

 

How can I check to make sure its loaded? I've gotten this far, need help to finish.

Speedstep.zip

[yeehaa]

Need some help please to get my speedstepping working.

 

Please see my attached C-States which I created.

 

I've compiled my DSDT with the SSDT and no errors.

 

I've deleted Disabler kext from E/E

 

CPU-i shows my temps at idle have gone up (55-58 degrees) and no stepping or changes show under the P-States tab of CPU-i.

 

How can I check to make sure its loaded? I've gotten this far, need help to finish.

 

you can see whether the pstates are "loaded" thus: (screenshot from IORegExplorer; i have 5 pstates)

 

your latency values seem to have some problem. look at the 3rd and 4th values in each package. i would change them both to 0x0A, for every single package.

btw, you are confusing between pstates and cstates!

 

Hello, I originally got P-states registered by following this guide but I haven't been able to get them working. I also get CST errors. I talked with Brett Whinnen, and made some modifications on his advice, but that did not end up changing things. I've got 17 P-states showing up in CPU-i, but the status always shows the same for both cores: 796 MHz, 8x multiplier, and 1.004 voltage. Interestingly enough though, that is not one of the P-states. The closest P-state listed is supposed to have 1.116 V.

 

For now I'd be happy just to get my P-states working, I suspect my C-state problem is the same as Brett's since we both have a Dell with a T9300. Does anyone have any suggestions?

 

17? but you have only 6 in your SSDT tables!

 

this is interesting:

 

Package (0x06)

{

0x0320,

0x2710,

0x0A,

0x0A,

0x8813,

0x8813

}

and you may wanna post your dsl rather than aml. people who are interested in helping most probably would be turned of by you presenting them with a compiled version.

[keeza]

you can see whether the pstates are "loaded" thus: (screenshot from IORegExplorer; i have 5 pstates)

 

your latency values seem to have some problem. look at the 3rd and 4th values in each package. i would change them both to 0x0A, for every single package.

btw, you are confusing between pstates and cstates!

 

Thanks for your reply, my brains have turned to mush!

 

I've attached my Ioreg output, it shows 6 data fields, are they my speedsteps?

 

I've changed the package values as you suggested, is this more like it?

 

And how can I check if speedstep is working? And does the second line in each package look OK (these I added myself)?

 

Thanks again, much appreciated.

Speedstep2.zip

[Beerkex'd]

I want a vanilla system, so I made a legacy appleLPC kext (it's the first one I made so if you know about how to make legacy kext don't hesitate to double check the plist and let me know) , anyway it's loading and working the way I made it (you know that it is loaded when the "Start up automatically... " option appear in the energy saver,[)

You can also patch the Device ID of the LPC in your DSDT as outlined here:

http://www.insanelymac.com/forum/index.php?showtopic=168014

 

Here's my patched LPC device:

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

...and vanilla AppleLPC.kext loads.

[yeehaa]

Thanks for your reply, my brains have turned to mush!

 

I've attached my Ioreg output, it shows 6 data fields, are they my speedsteps?

 

I've changed the package values as you suggested, is this more like it?

 

And how can I check if speedstep is working? And does the second line in each package look OK (these I added myself)?

 

Thanks again, much appreciated.

the corrected values seem okay. abt the first and second values in each of the packages u have to figure them out yourselves, coz they depend on your processor.

speedstep should work with the new values. (i guess, you've checked to make sure that SPSS or NPSS get loaded. the easiest way is to just add _PSS method and remove all the other things.) you should see it working in the "Status" tab in CPU-i

[keeza]

the corrected values seem okay. abt the first and second values in each of the packages u have to figure them out yourselves, coz they depend on your processor.

speedstep should work with the new values. (i guess, you've checked to make sure that SPSS or NPSS get loaded. the easiest way is to just add _PSS method and remove all the other things.) you should see it working in the "Status" tab in CPU-i

 

OK, I've recompiled with those changes to the latency values as you suggested.

Disabler kext is deleted.

 

Under status tab CPUi it seems to be running on the highest which in my case is 2664Mhz x8 multiplier. It doesnt change if I run CPUtest.

So it doesnt appear to be running yet.

I've attached my DSDT, the SSDT part should be complete.

 

I haven't checked to see if the NPSS or SPSS has loaded, could you step me through that please?

MyDSDT.zip

[Squirrelf]

You can also patch the Device ID of the LPC in your DSDT as outlined here:

http://www.insanelymac.com/forum/index.php?showtopic=168014

 

Here's my patched LPC device:

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

...and vanilla AppleLPC.kext loads.

 

 

cool I prefer that than my legacy kext

[yeehaa]

OK, I've recompiled with those changes to the latency values as you suggested.

Disabler kext is deleted.

 

Under status tab CPUi it seems to be running on the highest which in my case is 2664Mhz x8 multiplier. It doesnt change if I run CPUtest.

So it doesnt appear to be running yet.

I've attached my DSDT, the SSDT part should be complete.

 

I haven't checked to see if the NPSS or SPSS has loaded, could you step me through that please?

 

you messed up!

replace your

Scope (\_PR)
{
	Processor (CPU0, 0x00, 0x00000410, 0x06) {}
	Processor (CPU1, 0x01, 0x00000410, 0x06) {}
	Processor (CPU2, 0x02, 0x00000410, 0x06) {}
	Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}

section with the "stuff" in the attached text file and remove the whole SSDT tables from your dsdt.aml. this is the easiest way to test whether speedstep works or not. if it does not, it has to be some problem with the values within the package and there i wont be able to help ya.

keeza.txt

[keeza]

you messed up!

replace your

Scope (\_PR)
 {
	 Processor (CPU0, 0x00, 0x00000410, 0x06) {}
	 Processor (CPU1, 0x01, 0x00000410, 0x06) {}
	 Processor (CPU2, 0x02, 0x00000410, 0x06) {}
	 Processor (CPU3, 0x03, 0x00000410, 0x06) {}
 }

section with the "stuff" in the attached text file and remove the whole SSDT tables from your dsdt.aml. this is the easiest way to test whether speedstep works or not. if it does not, it has to be some problem with the values within the package and there i wont be able to help ya.

keeza.txt

 

Yeehaa,

Did as you suggested. get Parseop errors when compiling.

 

Gonna leave it for today and have another look tomorrow.

 

Thanks though

[yonika]

First of all, I must say that from my point of view this is not an argument but an interesting discussion, and now that I cleared that up, I can say this:

 

power is calculated in one of three ways:

1. Power = Voltage x Current

2. Power = Voltage^2 / Resistance

3. Power = Current^2 * Resistance

 

At first look, it seems like if you reduce voltage, power will drop, but no one promises that current stays the same, if load is increased power can be left the same and might even be higher.

 

But that's not the issue, the issue is, that I still don't understand when and what I should see if I have c-states working on my system ? Should I look at the voltages ? should they drop below the lowest p-state voltage - in my settings 1.132v ? or should I look in another place in cpu-i for a real power measurement in milli Watts ?

 

I honestly don't understand what I should look for, So please help me, a screen shot would be really appreciated.

 

Thanks,

Jonathan

 

 

 

 

I also don't have CST error when c-states are enabled in bios,see post #125, I can also add that using the dropSSDT=y flag does not change the absence of cst errors on boot.

 

Jonathan

 

Jeez Guys,

 

Would someone finally explain/show exactly how to check if c-states are working ?

 

I guess other guys here want to know if they have c-states operating or not, Except for not seeing the cst evaluation error.

 

Someone says voltage, someone says power, but no one says exactly where and what to look for in CPU-i (if there's support for that at all). if there's another method/application - say. if no one knows how to check that, say. just don't say half of the info and then ignore the following questions.

 

Thanks everyone and hope each and every one of you will get to see a day when his installation will have both p-states and c-states operating !!

 

Jonathan

[Squirrelf]

in my case with or without cstates the difference is visibly noticeable, I could't watch a movie sound and image would stutter/lag... and temperature were 10C lower idle (when appleLPC was loaded)

But I'm using MP3.1 cstates so maybe that's the reason of the shuttering

 

without cstates (p-states still there, with or without appleLPC) temperature would go back up 10C idle compared to before, but I could watch the movie without problem at all, it was silky smooth, p-states were still working

 

so I don't see the point of speedstep if temperature is higher at idle compared to having no speedstep at all (and using NullCPUPowerManagement)

 

help !

[Master Chief]

Jeez Guys,

 

Would someone finally explain/show exactly how to check if c-states are working ?

 

<snip />

 

Jonathan

There are only two real ways of telling that C-States are working. The first one being LED's on your motherboard and the second one is a PCI test card (hardware only). Other speculative info like stutter/slow response cannot be taken for real, at least not until there's some sort of proof to it.

 

One of the reasons that I started to look into the device-id change for my built-in network adapter (as a test) was to be able to flash my AMI BIOS with modified ROM modules. While this is not for the fainted hearts, but once that is done and I don't need LegacyYukon2.kext anymore, then I can replace other ROM modules, like module 10 (ACPI AML). Sort of saying goodbye to my /dsdt.aml and hopefully reduce the startup time.

[yeehaa]

Yeehaa,

Did as you suggested. get Parseop errors when compiling.

 

Gonna leave it for today and have another look tomorrow.

 

Thanks though

 

dude! the _PSS fix is not gonna magically remove all the other 164 errors in your DSDT! you need to have a "clean" DSDT before you start adding patches! are you using iasl? or some other compiler?

[Beerkex'd]

Okay, I finally had my breakthrough with this and I'm very excited . I have P-state switching (8 of them!) and I fixed the skipping sound.

I appended my SSDT tables (complete dump here: http://www.insanelym...p;#entry1258828 ) at the end of my DSDT following FormerlyKnownAs' example in the first post - carefully comparing my own SSDT dumps to his I picked the equivalent sections and inserted them one by one. I also followed Master Chief's advice (see earlier in the thread) and changed the 1 in Name (NPCP, 0x00000001) to a 2.

I have a C2D E8500 - so I removed all CPU references but CPU0 and CPU1 (probably not strictly necessary but it's cleaner). I also did some device renaming (not sure if that part is absolutely necessary either) to better match the DSDT of an iMac9,1, which is the model identifier I'm using.

Because Master Chief said it might make a difference, I changed the CPU labels to CPU0 and CPU1, they were P001 and P002 in the original DSDT.

 

Other than the renaming I've made some modifications to HPET, RTC, IPIC and TIMR devices, first copying some ideas from this blog here:

http://aserebln.blog...2009/07/20.html

..and later modifying them again, following THe KiNG's advice in the DSDT subforum over at the ProjectOSX forums. What got me started originally was the LPC device DSDT info posted here: http://www.insanelym...p;#entry1008957

As mentioned earlier in the thread, I have patched the LPC device ID in the DSDT so that AppleLPC.kext loads, using the method outlined by zhell here:

http://www.insanelym...howtopic=168014

As Superhai said in http://www.insanelym...p...t&p=1264201 it was a timing issue.

Thanks to ivik (see earlier in this thread) who alerted me to the fact that I was missing several lines of code from the P5Q-E's original DSDT in my HPET device - I guess it must have been patched out when using koalala's ACPI patcher.

 

I also did sudo pmset -a dps 1 - not sure if that's necessary either but it seemed like the right thing to do. type man pmset in terminal for more info.

Here's my DSDT: 1809_BK.dsl.zip

If you have a recent ASUS board with AMI BIOS you might be able to use some of the fixes, so take a look and take whatever you need.

Huge thanks to everyone who keeps pouring their knowledge and their findings into the community, you are all awesome. I'm really enjoying the ride.

 

Shouts and major props go out to my original partner in crime, Pere, 18seven for helping me fix my compiling errors and to the DSDT fairy (let's call him "R") who appears secretly in private messages once or twice a year

 

/EDIT

 

Does anyone have any idea why sysctl -a | grep freq doesn't reflect the minimum p-state?

 

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: 1335827200

hw.busfrequency_min: 1332000000

hw.busfrequency: 1332000000

 

All of you with working p-state switching - are you seeing the same thing? Is there a way, am I missing something?

[Squirrelf]

cpui will KP my system during boot if I don't have nullcpumanagement...

any ideas?

[Master Chief]

Okay, I finally had my breakthrough with this and I'm very excited . I have P-state switching (8 of them!) and I fixed the skipping sound.

Great! But why did you duplicate all objects but _CST? You might want to remove these, and use the objects in the first Processor block. Just a space saving nit of course.

 

<snip />

 

/EDIT

 

Does anyone have any idea why sysctl -a | grep freq doesn't reflect the minimum p-state?

 

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: 1335827200

hw.busfrequency_min: 1332000000

hw.busfrequency: 1332000000

 

All of you with working p-state switching - are you seeing the same thing? Is there a way, am I missing something?

Yeah. I have the same kind of problem with Chameleon v1.0.11 And a long time already.

 

cpui will KP my system during boot if I don't have nullcpumanagement...

any ideas?

Have you recompiled it, or are you just using the distributed copies?

[Master Chief]

I kept wondering why some people here had SSDT tables in their ACPI table, while others, including me had not. I noticed that the RSDT table on my Mac was different than the one on the hack so I searched and found this:

 

"When OSPM locates the structure, it looks at the physical address for the Root System Description Table or the Extended System Description Table. The Root System Description Table starts with the signature “RSDT”, while the Extended System Description Table starts with the signature “XSDT”. These tables contain one or more physical pointers to other system description tables that provide various information about the system. As shown in Figure 5-1, there is always a physical address in the Root System Description Table for the Fixed ACPI Description table (FADT).

 

When OSPM follows a physical pointer to another table, it examines each table for a known signature. Based on the signature, OSPM can then interpret the implementation-specific data within the description table.

 

The purpose of the FADT is to define various static system information related to configuration and power management. The Fixed ACPI Description Table starts with the “FACP” signature. The FADT describes the implementation and configuration details of the ACPI hardware registers on the platform."

 

This is the RSDT of a MacPro3,1:

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20080926
*
* Disassembly of RSDT.dat, Sat Sep 19 13:56:53 2009
*
* ACPI Data Table [XSDT]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 000  4]                    Signature : "XSDT"    /* Extended System Description Table */
[004h 004  4]                 Table Length : 000000EC
[008h 008  1]                     Revision : 01
[009h 009  1]                     Checksum : 47
[00Ah 010  6]                       Oem ID : "APPLE "
[010h 016  8]                 Oem Table ID : "Apple00 "
[018h 024  4]                 Oem Revision : 0000006C
[01Ch 028  4]              Asl Compiler ID : "    "
[020h 032  4]        Asl Compiler Revision : 01000013

[024h 036  8]       ACPI Table Address   0 : 000000007F740000
[02Ch 044  8]       ACPI Table Address   1 : 000000007F742000
[034h 052  8]       ACPI Table Address   2 : 000000007F73F000
[03Ch 060  8]       ACPI Table Address   3 : 000000007F73D000
[044h 068  8]       ACPI Table Address   4 : 000000007F73C000
[04Ch 076  8]       ACPI Table Address   5 : 000000007F736000
[054h 084  8]       ACPI Table Address   6 : 000000007F735000
[05Ch 092  8]       ACPI Table Address   7 : 000000007F734000
[064h 100  8]       ACPI Table Address   8 : 000000007F733000
[06Ch 108  8]       ACPI Table Address   9 : 000000007F732000
[074h 116  8]       ACPI Table Address  10 : 000000007F731000
[07Ch 124  8]       ACPI Table Address  11 : 000000007F730000
[084h 132  8]       ACPI Table Address  12 : 000000007F72F000
[08Ch 140  8]       ACPI Table Address  13 : 000000007F72E000
[094h 148  8]       ACPI Table Address  14 : 000000007F72D000
[09Ch 156  8]       ACPI Table Address  15 : 000000007F72C000
[0A4h 164  8]       ACPI Table Address  16 : 000000007F72B000
[0ACh 172  8]       ACPI Table Address  17 : 000000007F72A000
[0B4h 180  8]       ACPI Table Address  18 : 000000007F729000
[0BCh 188  8]       ACPI Table Address  19 : 000000007F728000
[0C4h 196  8]       ACPI Table Address  20 : 000000007F727000
[0CCh 204  8]       ACPI Table Address  21 : 000000007F726000
[0D4h 212  8]       ACPI Table Address  22 : 000000007F722000
[0DCh 220  8]       ACPI Table Address  23 : 000000007F71D000
[0E4h 228  8]       ACPI Table Address  24 : 000000007F71A000

Raw Table Data

 0000: 58 53 44 54 EC 00 00 00 01 47 41 50 50 4C 45 20  XSDT.....GAPPLE 
 0010: 41 70 70 6C 65 30 30 20 6C 00 00 00 20 20 20 20  Apple00 l...    
 0020: 13 00 00 01 00 00 74 7F 00 00 00 00 00 20 74 7F  ......t...... t.
 0030: 00 00 00 00 00 F0 73 7F 00 00 00 00 00 D0 73 7F  ......s.......s.
 0040: 00 00 00 00 00 C0 73 7F 00 00 00 00 00 60 73 7F  ......s......`s.
 0050: 00 00 00 00 00 50 73 7F 00 00 00 00 00 40 73 7F  .....Ps......@s.
 0060: 00 00 00 00 00 30 73 7F 00 00 00 00 00 20 73 7F  .....0s...... s.
 0070: 00 00 00 00 00 10 73 7F 00 00 00 00 00 00 73 7F  ......s.......s.
 0080: 00 00 00 00 00 F0 72 7F 00 00 00 00 00 E0 72 7F  ......r.......r.
 0090: 00 00 00 00 00 D0 72 7F 00 00 00 00 00 C0 72 7F  ......r.......r.
 00A0: 00 00 00 00 00 B0 72 7F 00 00 00 00 00 A0 72 7F  ......r.......r.
 00B0: 00 00 00 00 00 90 72 7F 00 00 00 00 00 80 72 7F  ......r.......r.
 00C0: 00 00 00 00 00 70 72 7F 00 00 00 00 00 60 72 7F  .....pr......`r.
 00D0: 00 00 00 00 00 20 72 7F 00 00 00 00 00 D0 71 7F  ..... r.......q.
 00E0: 00 00 00 00 00 A0 71 7F 00 00 00 00              ......q.....

 

And this of the hack:

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20080926
*
* Disassembly of RSDT.dat, Sat Sep 19 13:45:06 2009
*
* ACPI Data Table [XSDT]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 000  4]                    Signature : "XSDT"    /* Extended System Description Table */
[004h 004  4]                 Table Length : 00000054
[008h 008  1]                     Revision : 01
[009h 009  1]                     Checksum : A9
[00Ah 010  6]                       Oem ID : "A_M_I_"
[010h 016  8]                 Oem Table ID : "OEMXSDT "
[018h 024  4]                 Oem Revision : 12000816
[01Ch 028  4]              Asl Compiler ID : "MSFT"
[020h 032  4]        Asl Compiler Revision : 00000097

[024h 036  8]       ACPI Table Address   0 : 0000000000DEB000
[02Ch 044  8]       ACPI Table Address   1 : 00000000CFF80390
[034h 052  8]       ACPI Table Address   2 : 00000000CFF80400
[03Ch 060  8]       ACPI Table Address   3 : 00000000CFF8E040
[044h 068  8]       ACPI Table Address   4 : 00000000CFF88F80
[04Ch 076  8]       ACPI Table Address   5 : 00000000CFF88FC0

Raw Table Data

 0000: 58 53 44 54 54 00 00 00 01 A9 41 5F 4D 5F 49 5F  XSDTT.....A_M_I_
 0010: 4F 45 4D 58 53 44 54 20 16 08 00 12 4D 53 46 54  OEMXSDT ....MSFT
 0020: 97 00 00 00 00 B0 DE 00 00 00 00 00 90 03 F8 CF  ................
 0030: 00 00 00 00 00 04 F8 CF 00 00 00 00 40 E0 F8 CF  ............@...
 0040: 00 00 00 00 80 8F F8 CF 00 00 00 00 C0 8F F8 CF  ................
 0050: 00 00 00 00                                      ....

This explains the missing tables. Nothing more. And you might be smart/brave (stupid?) enough to flash a modified BIOS ROM. I however really hope that we can find a low-profile solution for everyone.

[Beerkex'd]

Great! But why did you duplicate all objects but _CST? You might want to remove these, and use the objects in the first Processor block. Just a space saving nit of course.

 

I did the same thing FKA did, I just inserted all the tables I had that matched up to his, in the same order. I know about the multiple Scope \PRs for each CPU, I will try to merge them later. The solution given to me by ivik had everything under the Scope \PR in the beginning of the DSDT like you say. I just couldn't get that to work initially for whatever reason. I probably overlooked something.

 

Yeah. I have the same kind of problem with Chameleon v1.0.11 And a long time already.

 

I'm using stock 2.0 RC3 here.

 

What does Chameleon have to do with clock frequencies? Some EFI voodoo happening?