DSDT - Vanilla Speedstep - Generic Scope (_PR)

[spanakorizo]

I'm done patching. Now I'm running super stable with speed step fully working!!

 

Here's a simple summary of what I did for those who care:

+Add the _CST from a MacPro3,1 (Removes all errors at startup)

+Add an LPC device with a fake id to match Apple's LPC kext (allows me to remove the legacyLPC)

+Remove IRQs from from TMR and PIC (fixes sound stuttering)

 

What I didn't do is:

-Change model identifier in smbios.plist (still imac5,2)

-Edit any kext (all vanilla)

-Add SSDT tables to the DSDT (which, as I said before, is a bit surprising)

 

Result:

Speed Step fully working reducing both CPU frequency and voltage. CPU temp idles at 30C instead of 50C before this.

same here, right now i am testing.Temps are lower in idle but i think my voltages are still high for idle pstates, so i can go even cooler.

some questions:

a)are u OC?

if u are, did u set voltages from bios etc or it's not necessary as dsdt overrides bios settings?

what are your voltages?

can u set voltages through the _PSS, Package or it goes automatically?

 

i have those pstates in my dsdt (taken from pstate calculator with a little maths by myself)

  Package (0x06) { 3003, 64092, 10, 10, 0x926, 0x926 },
Package (0x06) { 2736, 54576, 10, 10, 0x824, 0x824 },
Package (0x06) { 2403, 44092, 10, 10, 0x726, 0x726 },
Package (0x06) { 2136, 35576, 10, 10, 0x624, 0x624 }

it is ok?

 

SSDT Tables:

Me 2 didnt add SSDT tables, only PStates (4) and _cst ,could u give an example to add and test?

and at last:

+Add an LPC device with a fake id to match Apple's LPC kext (allows me to remove the legacyLPC)

what do u mean by that? i can see from extensions that applelpc is loaded, do i miss something?

 

/bombed by information

 

cpui stats:

[Brett Whinnen]

Any recommendations on a CPU monitoring utility for Snow similar to CPUi? Want to see if my stepping still works.

 

MSR doesn't work on my system under Snow (maybe not compatible?) I'm booting with -32 flag.

 

And yes, I've just updated to Snow Leopard from 10.5.8

 

All seems to be good except some sound assertion errors on boot which I'll look into.

 

 

man, Snow is fast!

 

 

Would you care to explain where in my dsdt I could find this? Can't have that!

 

 

I know the feeling. After a little while on SL I've noticed a few little things I need to iron out relating to my stepping.

 

For SL I use CoolBookController to monitor both stepping and temp. It seems to work quite well, I don't know where it picks up the values for the Pstates from though as the max one it has is 2.7GHz which my CPU doesn't do, (a T9300), my max pstate is only 2.5GHz as calculated in my _PSS entries. But I can see it jump from 800MHz to 2.5GHz depending on what I am doing.

 

Oh and I just boot into 64bit as that was default. It works and so does everything I run so far.

 

As to your DSDT you posted look for line number 6220, you'll see above it that you only load the IST0 table, you don't actually load the CST0 table.

                    If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02
                           )))
                       Load (IST0, HI0)
                   }

                   Store (0x01, TLD0)

 

But if you look at the line starting 6240 you'll see both tables being loaded for CPU1.

                    If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05
                           )))
                       Load (IST1, HI1)
                   }

                   If (And (CFGD, 0x10))
                   {
                       OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
                           )))
                       Load (CST1, HC1)
                   }

                   Store (0x01, TLD1)

 

So check your original SSDT to make sure you get the index values right for grabbing the CST values from the SSDT (i.e. you can't just copy the line above and change CST1 to CST0 and HC1 to HC0...

 

Before you made the modification to your DSDT for the LPC device to inject the apple deviceID did you get AppleLPC loading at all? If you did a kextstat was it there? And what errors did you see if you did a dmesg | grep ACPI ?

 

Thanks!

 

Brett

[Superhai]

For SL I use CoolBookController to monitor both stepping and temp. It seems to work quite well, I don't know where it picks up the values for the Pstates from though as the max one it has is 2.7GHz which my CPU doesn't do, (a T9300), my max pstate is only 2.5GHz as calculated in my _PSS entries. But I can see it jump from 800MHz to 2.5GHz depending on what I am doing.

 

2.7GHz is IDA mode. Which your CPU should perfectly be able to do.

[Brett Whinnen]

2.7GHz is IDA mode. Which your CPU should perfectly be able to do.

 

Do I just create the max Pstate to reflect that then? At the moment it is set to 2.5GHz and the next one down is 2.49GHz...

 

Top two pstates:

 

Package (0x06)

{

0x09C5,

0x7D00,

0x0A,

0x0A,

0x4D28,

0x4D28

},

 

Package (0x06)

{

0x09C4,

0x7918,

0x0A,

0x0A,

0x4C22,

0x4C22

},

[Superhai]

Do I just create the max Pstate to reflect that then? At the moment it is set to 2.5GHz and the next one down is 2.49GHz...

You should have a CTL value that is with the requested multiplier (i.e. a step higher than guaranteed max). I don't think there is a standard for how this should be coded in the _PSS table. And I am not sure how and if Apples own power management driver applies it. You need to have bit 32 cleared in IA32_PERF_CONTROL and the other core must be in a sub C1 state for the CPU to jump to the IDA state.

[Master Chief]

Demystifying P-State Loading

I installed Snow Leopard from the retail DVD for this exercise, and made no changes whatsoever. Here's a screen shot of System Profiler:

 

 

And here's one of Xcodes' IORegistry Explorer:

 

 

And both show P5K PRO simple because that's what I use, and because I use Chameleon v1.0.11 as boot loader – the one without SMBIOS patching capabilities – so that's what I get. I can change it, yes, but I rather do not (to show you what needs to be changed).

 

I used a clean vanilla DSDT dump for this exercise, one without any modifications whatsoever related to P-States and C-States, and as a result I have the following two errors in kernel.log:

 

Sep 29 07:13:57 Master-Chiefs-Mac kernel[0]: ACPI_SMC_PlatformPlugin::pushCPU_CSTData - _CST evaluation failed
Sep 29 07:13:57: --- last message repeated 1 time ---
Sep 29 07:13:57 Master-Chiefs-Mac kernel[0]: ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

 

My AMI BIOS (1303) has two default P-States, showing up as PerformanceStateArray under ACPI_SMC_PlatformPlugin. Here's a screen shot of it:

 

 

And without any modification whatsoever, my CPU appears to be running at full speed:

 

 

Note: I have stated otherwise, but that was on Leopard where the model identifier is changed to MacPro3,1 by the use of Chameleon with SMBIOS patching aka ChameleonSM v1.0.12 (doesn't work with Snow Leopard).

 

And adding the following code to my DSDT:

Name (_PSS, Package (0x04)
{
Package (0x06) { 2498, 88000, 10, 10, 0x4720, 0x0000 },
Package (0x06) { 2331, 59643, 10, 10, 0x071E, 0x0001 },
Package (0x06) { 2165, 51124, 10, 10, 0x461C, 0x0002 },
Package (0x06) { 1998, 41880, 10, 10, 0x061A, 0x0003 }
})

To the first processor declaration block (Processor (CPU1, 0x01, 0x00000810, 0x06) {}) only results in this:

 

 

No change in CPU speed whatsoever, but what is more interesting is that commenting out the Load() statement, results in this:

 

 

As in no more PerformanceStateArray.

 

And that simply proves that my otherwise invisible IST data is in fact loaded through this statement. Let's just say that I won't RIP my Processor definition blocks to something like this:

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

Simply because there are rather important objects in it, and I don't want to fry another CPU.

 

More to come in part II after the break. PhotoBucket is back on-line again so here we go...

 

Now. At this stage I still block Load() from loading my IST tables (from BIOS) and I also removed my customized _PSS() object and thus this is what I get in IORegistry Explorer:

 

 

The next thing I did was to replaced MacPro3,1 in Info.plist to P5K PRO – all five of them – and went on with my testing after a reboot to find this:

 

 

Note the new properties and the added values!

 

Ok, still only two default P-States. Well. Let's make that four again... by adding my customized _PSS() object. And only on the first Processor declaration, simply because that's where ACPI_SMC_PlatformPlugin.kext expects it to be (matching based on IOCPUNumber = 0). And here's what that looks like:

 

 

And CPU-i not only starts up again (needs P-State data) but also shows all changes including: Frequency, Multiplier, Voltage and Temperature. Here's the result:

 

 

And here's how a custom _CST() object affects the temperatures with a reported case temperature of 41 centigrade (in the BIOS):

 

 

Note that the C-States aren't even working here/at this moment (CFGD set to 0x01000007) but changing this value will be part of my next exercise.

 

Conclusion

We P5K PRO user do not need a _CST() object to get P-States working, however, the temperatures are much higher without it. Not only that, the two errors in kernel.log will also be there. Next step is C-State activation!

 

Note: See post #358 for additional P-State information.

[keeza]

As to your DSDT you posted look for line number 6220, you'll see above it that you only load the IST0 table, you don't actually load the CST0 table.

Thanks I'll look into that.

 

 

Before you made the modification to your DSDT for the LPC device to inject the apple deviceID did you get AppleLPC loading at all? If you did a kextstat was it there? And what errors did you see if you did a dmesg | grep ACPI ?

 

I was unable to load LPC without the dsdt injection. The way I would check is by looking under Energy Saver under Sys Prefs and if "Start up automatically after a power failure" option was there I would know it had loaded. That was under 10.5.8. Yes it was there when I ran kextstat (although I only have learned about this command recently)

 

Not sure what the dmesg grep command does but have just ran it and got "Unable to obtain kernel buffer: operation not permitted". Not sure what that means but not concerned about it at the moment.

 

Under 10.5.8 CStates works perfectly.

Under Snow I have a slightly different IOreg output - I have attached a pic.

I also seem to have lost QE and CI from my graphics although my display still shows translucency etc.

 

One thing I learned about my CState dump was that initially when I did the dump C3 and C4 wasnt enabled in BIOS. I subsequently enabled them and redumped and got totally different CState values.

Obvious I know but sometimes the obvious.....

[oldnapalm]

I would like to try CST from MacPro3,1 SSDT dump, as various people reported to get SpeedStep working using it. The problem is that it uses PDC0 and I don't have it. Looking at other people SSDT dumps I found it comes from CPUPM, but looking at all my ACPI dumps from Linux I found that my system doesn't have CPUPM nor CPUCST, just CPUIST.

 

ACPI.zip

 

Can somebody help me with this?

 

Thanks a lot.

[Brett Whinnen]

Thanks I'll look into that.

 

 

 

 

I was unable to load LPC without the dsdt injection. The way I would check is by looking under Energy Saver under Sys Prefs and if "Start up automatically after a power failure" option was there I would know it had loaded. That was under 10.5.8. Yes it was there when I ran kextstat (although I only have learned about this command recently)

 

Not sure what the dmesg grep command does but have just ran it and got "Unable to obtain kernel buffer: operation not permitted". Not sure what that means but not concerned about it at the moment.

 

Under 10.5.8 CStates works perfectly.

Under Snow I have a slightly different IOreg output - I have attached a pic.

I also seem to have lost QE and CI from my graphics although my display still shows translucency etc.

 

One thing I learned about my CState dump was that initially when I did the dump C3 and C4 wasnt enabled in BIOS. I subsequently enabled them and redumped and got totally different CState values.

Obvious I know but sometimes the obvious.....

 

Ok my AppleLPC loads fine without any additions and I get the "Start up automatically after a power failure" is available as well as it being shown in kextstat, so I guess it is loaded properly

 

The dmesg | grep ACPI command is actually best to be run straight after booting as the dmesg output will vary as the system runs due to extra log entries. Basically it is searching through the most recent entries in /var/log/system.log for any line that has ACPI in it.

 

As to the QE/CI it doesn't show as hardware under Snow Leopard. If you do a OpenCL test it will show what devices are enabled from a hardware perspective. Also I've checked this with Aperture, which won't load up if there is no hardware acceleration available.

 

The joys of having a laptop with a cut down BIOS means I have no settings for C3 or C4 or anything like it actually...

 

Cheers

Brett

[keeza]

'Brett Whinnen' date='Sep 29 2009, 06:40 PM' post='1284043'

 

I can tell you now what was the "switch" that turned on CStates for me in Snow.

 

Look at my dsdt under the following:

 

Line 6337 - Added from MacPro3,1

Lines 6392-6393 - Added from MacPro3,1

Line 6448 - Added Bracket

 

6497+6498, 6460+6461, 6404+6405 added bit width and bit offset from MacPro3,1

 

Without any of the above CStates wouldn't load.

 

Hope this can help you get to the bottom of it.

 

Edit:

Everything else in this DSDT is from my original dump.

And lines 6221-6227 I added for CST0 - don't know if it did anything though

DSDT_with_CStates.zip

[FKA]

Not sure what the dmesg grep command does but have just ran it and got "Unable to obtain kernel buffer: operation not permitted". Not sure what that means but not concerned about it at the moment.

 

try running sudo dmesg

[mm67]

I can tell you now what was the "switch" that turned on CStates for me in Snow.

 

Look at my dsdt under the following:

 

Line 6337 - Added from MacPro3,1

Lines 6392-6393 - Added from MacPro3,1

Line 6448 - Added Bracket

 

6497+6498, 6460+6461, 6404+6405 added bit width and bit offset from MacPro3,1

 

Without any of the above CStates wouldn't load.

 

Hope this can help you get to the bottom of it.

 

Edit:

Everything else in this DSDT is from my original dump.

And lines 6221-6227 I added for CST0 - don't know if it did anything though

 

Have You tried running Geekbench with this one. I tried a similar one but Geekbench score fell down by 2000 points.

[dong]

My T60 has PSS and CST tables in the BIOS, so I don't have the error msgs in kernel.log. In this case, adding them to DSDT won't help.

The problem is that if I do not disable AppleIntelCPUPowermanagement.kext, it will mostly cause a KP within 5 minutes after the desktop show up. In some rare boots, it works just fine without KP, but you can not figure out the reason. This is all in 32 bit kernel.

With 64 bit kernel, AppleIntelCPUPowermanagement.kext won't cause KP at all. But another issue pop out, multiple instances of SoftwareUpdateCheck mysteriously keep launching by itself and eat a lot of CPU time which may eventually cause a KP.

I have to stick to NullCPUPowermanagemnet.kext which remove all the problems.

[keeza]

Have You tried running Geekbench with this one. I tried a similar one but Geekbench score fell down by 2000 points.

 

My Geekbench actually increased slightly from 6100 under Leopard to 6358 under Snow. Still down since adding PState and CStates by about 1000 points but a small performance hit might be something I have to live with till someone comes up with a cause.

 

Just a little of topic, how can I switch between 32 and 64bit when booting - is it a flag added in boot.plist? And how can I check to see which one (32 or 64) is running?

 

try running sudo dmesg

 

Thanks for that.

 

May I ask what that command does?

 

I have run it and other than my sound assertion errors and a firewire defaulting to secure and a ethernet timeout I'm good.

 

The sound and ethernet issues I can resolve.

Firewire I've had since 10.5.8 - couldn't get to the bottom of that one.

 

Drifting off topic again, sorry......

[yeehaa]

My T60 has PSS and CST tables in the BIOS, so I don't have the error msgs in kernel.log. In this case, adding them to DSDT won't help.

The problem is that if I do not disable AppleIntelCPUPowermanagement.kext, it will mostly cause a KP within 5 minutes after the desktop show up. In some rare boots, it works just fine without KP, but you can not figure out the reason. This is all in 32 bit kernel.

With 64 bit kernel, AppleIntelCPUPowermanagement.kext won't cause KP at all. But another issue pop out, multiple instances of SoftwareUpdateCheck mysteriously keep launching by itself and eat a lot of CPU time which may eventually cause a KP.

I have to stick to NullCPUPowermanagemnet.kext which remove all the problems.

 

did u try the IRQ fixes? the one's posted by king over there at project?

[mm67]

Now I got the full Geekbench score back. I replaced this:

        Method (_PSS, 0, NotSerialized)
       {
           If (LEqual (And (CFGD, 0x00060000), 0x00020000))
           {
               Return (SPSS)
           }

           If (LEqual (And (CFGD, 0x00060000), 0x00040000))
           {
               Return (NPSS)
           }

           If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000)))
           {
               Return (NPSS)
           }

           Return (SPSS)
       }

       Name (SPSS, Package (0x06)
       {
	Package (0x06)	// First P-Sate
	{
		0x00000B0F,		// 2831 Mhz in hex
		0x00017318,		// 95000mv in hex
		0x000000A0,
		0x0000000A,
		0x00004826,             
		0x00004826              // FID=8.5, VID=38
	},

	Package (0x06)	// Second P-Sate
	{
		0x00000A68,		// 2664 Mhz in hex
		0x00014FF0,		// 86000mv in hex
		0x000000A0,
		0x0000000A,
		0x00000823,             
		0x00000823              // FID=8, VID=35
	},

	Package (0x06)	// Third P-Sate
	{
		0x000009C2,		// 2498 Mhz in hex
		0x000130B0,		// 78000mv in hex
		0x000000A0,
		0x0000000A,
		0x00004720,             
		0x00004720              // FID=7.5, VID=32
	},

	Package (0x06)	// Fourth P-Sate
	{
		0x0000091B,		// 2331 Mhz in hex
		0x00011170,		// 70000mv in hex
		0x000000A0,
		0x0000000A,
		0x0000071D,            
		0x0000071D  	  	// FID=7, VID=29
	},

	Package (0x06)	// Fifth P-Sate
	{
		0x00000875,		// 2165 Mhz in hex
		0x0000F230,		// 62000mv in hex
		0x000000A0,
		0x0000000A,
		0x0000461A,             
		0x0000461A		// FID=6.5, VID=26
	},

	Package (0x06)	// Sixth P-Sate
	{
		0x000007CE,		// 1998 Mhz in hex
		0x0000D6D8,		// 55000mv in hex
		0x000000A0,
		0x0000000A,
		0x00000617,		
		0x00000617		// FID=6, VID=23
               }
       })

       Name (NPSS, Package (0x06)
       {
	Package (0x06)	// First P-Sate
	{
		0x00000B0F,		// 2831 Mhz in hex
		0x00017318,		// 95000mv in hex
		0x000000A0,
		0x0000000A,
		0x00004826,             
		0x00004826              // FID=8.5, VID=38
	},

	Package (0x06)	// Second P-Sate
	{
		0x00000A68,		// 2664 Mhz in hex
		0x00014FF0,		// 86000mv in hex
		0x000000A0,
		0x0000000A,
		0x00000823,             
		0x00000823              // FID=8, VID=35
	},

	Package (0x06)	// Third P-Sate
	{
		0x000009C2,		// 2498 Mhz in hex
		0x000130B0,		// 78000mv in hex
		0x000000A0,
		0x0000000A,
		0x00004720,             
		0x00004720              // FID=7.5, VID=32
	},

	Package (0x06)	// Fourth P-Sate
	{
		0x0000091B,		// 2331 Mhz in hex
		0x00011170,		// 70000mv in hex
		0x000000A0,
		0x0000000A,
		0x0000071D,            
		0x0000071D  	  	// FID=7, VID=29
	},

	Package (0x06)	// Fifth P-Sate
	{
		0x00000875,		// 2165 Mhz in hex
		0x0000F230,		// 62000mv in hex
		0x000000A0,
		0x0000000A,
		0x0000461A,             
		0x0000461A		// FID=6.5, VID=26
	},

	Package (0x06)	// Sixth P-Sate
	{
		0x000007CE,		// 1998 Mhz in hex
		0x0000D6D8,		// 55000mv in hex
		0x000000A0,
		0x0000000A,
		0x00000617,		
		0x00000617		// FID=6, VID=23
               }
       })
   }

 

with this:

        Method (_PSS, 0, NotSerialized)
       {
           Return (SPSS)
       }

       Name (SPSS, Package (0x02)
       {
	Package (0x06)
	{
		0x00000B0F,
		0x00017318,
		0x000000A0,
		0x0000000A,
		0x00004820,             
		0x00004820
	},

	Package (0x06)
	{
		0x000007CE,
		0x0000D6D8,
		0x000000A0,
		0x0000000A,
		0x00000616,		
		0x00000616
               }
       })

[oldnapalm]

Hey Master Chief, thanks for the great explanation.

 

I followed your steps and got very close results (4 values under PerformanceStateArray after adding _PSS for my CPU and Step2_0), except that after adding _CST from MacPro3,1 temperatures are still high (> 60º C idle). The main difference here is that my SSDT doesn't have PDC0 so I gave a shot in the dark and used 0x80000000.

 

Using NullCPUPowerManagement.kext and C1E enabled in BIOS I have decent temperatures (40-43º C idle) and CPU-i shows changes in frequency/multiplier/voltage, but only for cores 1 and 2, and between 2 states (my CPU has 4).

 

In Leopard SpeedStep works for all cores using Superhai's VoodooPowerMini.kext, waiting for 64 bit version.

[Brett Whinnen]

Well I had some interesting findings this morning...

 

I've stripped all the SSDT related information out of my DSDT (also removed the DropSSDT=Y from com.apple.Boot.plist) as I wanted to start over again from the beginning...

 

Well lo and behold I have full speedstep enabled. CoolBook Controller lists the same states, the IORegistryExplorer reports the same 6 power states. I do get the "ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized" error still but I'll start on that again later...

 

Under ACPITables I can see my DSDT loaded as well as a separate SSDT.

 

I'm confused! The only difference between this DSDT and the old one that was used for us M1530 laptop owners is the HPET is actually closer to that of a real Mac and thus the AppleIntelCPUPowerManagement now loads fine.

 

This is my _PR scope now...

   Scope (_PR)
   {
       Processor (CPU0, 0x00, 0x00001010, 0x06)
       {
       }

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

 

I no longer have the SSDT definition in there, no _PSS, nothing. So I'm now just throwing my hands up in the air thinking I did all that work to get PSTATES working when they would vanilla... So the issue must be with a mis-match in the number of CSTATES I have in my SSDT compared to what ACPI_SMC is expecting to see? Would that be a fair call?

 

Thanks again for looking...

 

Brett

[thestevo]

Well, the P-States provided by the system are wrong, as I explained in a PM. Not only is there not a proper entry for IDA, but it doesn't allow one to use the 600MHz P-State either.

[Brett Whinnen]

Well, the P-States provided by the system are wrong, as I explained in a PM. Not only is there not a proper entry for IDA, but it doesn't allow one to use the 600MHz P-State either.

 

Was that to me? If so I don't have a PM from you outlining any issues with the system _PSS values, just one asking about getting _PSS values working

 

Even searching Intel's site I didn't see a 600MHz pstate for the T9300, the lowest I saw was 800MHz...

 

But anyways any further info you have found is always good

[Master Chief]

did u try the IRQ fixes? the one's posted by king over there at project?

I would like to call that a "workaround" and not a "fix". Why? Well, let's have a look at the RTC from a real MacPro3,1:

				Device (RTC)
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (BUF0, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x08,			   // Length
						)
				})
				Name (BUF1, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x08,			   // Length
						)
					IRQNoFlags ()
						{8}
				})
				Method (_CRS, 0, Serialized)
				{
					If (HPAE)
					{
						Return (BUF0)
					}

					Return (BUF1)
				}
			}

 

And here's TIMR from the same MacPro3,1:

				Device (TIMR)
			{
				Name (_HID, EisaId ("PNP0100"))
				Name (BUF0, ResourceTemplate ()
				{
					IO (Decode16,
						0x0040,			 // Range Minimum
						0x0040,			 // Range Maximum
						0x01,			   // Alignment
						0x04,			   // Length
						)
					IO (Decode16,
						0x0050,			 // Range Minimum
						0x0050,			 // Range Maximum
						0x10,			   // Alignment
						0x04,			   // Length
						)
				})
				Name (BUF1, ResourceTemplate ()
				{
					IO (Decode16,
						0x0040,			 // Range Minimum
						0x0040,			 // Range Maximum
						0x01,			   // Alignment
						0x04,			   // Length
						)
					IO (Decode16,
						0x0050,			 // Range Minimum
						0x0050,			 // Range Maximum
						0x10,			   // Alignment
						0x04,			   // Length
						)
					IRQNoFlags ()
						{0}
				})
				Method (_CRS, 0, Serialized)
				{
					If (HPAE)
					{
						Return (BUF0)
					}

					Return (BUF1)
				}
			}

 

Now note the if (HPAE) {} clause here, which is what makes it fly on a MacPro3,1 However, nobody ever explained, really, why you should remove the IRQ's. Is that because they simply never solved this piece of the puzzle, or am I missing something here?

 

It is still very early for me, but what was HPAE again? Let's start with that first. Thanks.

 

p.s. Here's a clue:

    OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)
   Field (RCRB, DWordAcc, Lock, Preserve)
   {
               Offset (0x1000), 
               Offset (0x3000), 
               Offset (0x3404), 
       HPAS,   2, 
           ,   5, 
       HPAE,   1, 
               Offset (0x3418), 
           ,   1, 
       PATD,   1, 
       SATD,   1, 
       SMBD,   1, 
       HDAD,   1, 
       A97D,   1, 
               Offset (0x341A), 
       RP1D,   1, 
       RP2D,   1, 
       RP3D,   1, 
       RP4D,   1, 
       RP5D,   1, 
       RP6D,   1
   }

And here's mine:

	OperationRegion (RCRB, SystemMemory, 0xFED1F404, 0x04)
Field (RCRB, AnyAcc, NoLock, Preserve)
{
	HPAS,   2, 
		,   5, 
	HPAE,   1, 
			Offset (0x04)
}

It's not that big because we don't need the references to the rest. BTW: Do any of these ring a bell? But don't tell me because I know what they are

 

And here's an example, in this case my HPET from my hack:

                Device (HPET)
               {
                   Name (_HID, EisaId ("PNP0103"))
                   Name (BUF0, ResourceTemplate ()
                   {
                       IRQNoFlags ()
                           {0}
                       IRQNoFlags ()
                           {8}
                       Memory32Fixed (ReadOnly,
                           0xFED00000,         // Address Base
                           0x00000400,         // Address Length
                           _Y09)
                   })

                   Method (_STA, 0, NotSerialized)
                   {
                       If (LGreaterEqual (OSYS, 0x07D1))
                       {
                           If (HPAE)
                           {
                               Return (0x0F)
                           }
                       }
                       Else
                       {
                           If (HPAE)
                           {
                               Return (0x0B)
                           }
                       }

                       Return (Zero)
                   }

                   Method (_CRS, 0, NotSerialized)
                   {
                       if (HPAE)
                       {
                           CreateDWordField (CRS, \_SB.PCI0.LPCB.HPET._Y09._BAS, HPT0)
                           Multiply (HPAS, 0x1000, Local0)
                           Add (Local0, 0xFED00000, HPT0)
                       }
                       Return (BUF0)
                   }
               }

Making it look even more like a real MacPro3,1 – be it a little more optimized – but more importantly... no stutter for me

 

Hey Master Chief, thanks for the great explanation.

You're welcome.

 

I followed your steps and got very close results (4 values under PerformanceStateArray after adding _PSS for my CPU and Step2_0), except that after adding _CST from MacPro3,1 temperatures are still high (> 60º C idle). The main difference here is that my SSDT doesn't have PDC0 so I gave a shot in the dark and used 0x80000000.

ASUS uses TYPE instead of PDC0 and I think that was why FormelyKnownAs asked you to read the thread

[THe KiNG]

I would like to call that a "workaround" and not a "fix". Why? Well, let's have a look at the RTC from a real MacPro3,1:

When you compare two x58 boards(what I did) you should use DSDT from MacPro4,1, and is not a workaround is a fix, Apple chose to not use IRQ's on RTC and TIMR and I explained why it cause trouble on our hacks.

Anyway those checks from MacPro3,1 does the same thing, returns _CRS w/o IRQ's when HPET has _STA 0x0F, so you can remove them to save space and code in your DSDT.

[Master Chief]

When you compare two x58 boards(what I did) you should use DSDT from MacPro4,1, and is not a workaround is a fix, Apple chose to not use IRQ's on RTC and TIMR and I explained why it cause trouble on our hacks.

Anyway those checks from MacPro3,1 does the same thing, returns _CRS w/o IRQ's when HPET has _STA 0x0F, so you can remove them to save space and code in your DSDT.

Let me digg up a source file, from Apple, and get back to you a.s.a.p.

 

EDIT: I'll add it when I find it – I can't even remember where or when I've seen it (:

[oldnapalm]

ASUS uses TYPE instead of PDC0 and I think that was why FormelyKnownAs asked you to read the thread

 

Thank you.

Anyways, TYPE value is 0x80000000 here, so no changes at all.

[dong]

did u try the IRQ fixes? the one's posted by king over there at project?

[update]

Well, it turned out the first reboot after IRQ modification happened to be the rare case where there is no KP. Following reboots result in KP just like before. Sadly it does not solve my KP problem.

 

I'm here to confirm that this works for me, no more KP.

Thanks THe King a lot for the tip.

 

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here: