Master Chief's P5K PRO ACPI Warfare

[Master Chief]

Hi,

could you please post the link for CPU-i client app, since I'm using the kext you posted for CPU-i and the actual client application doesn't work on my system? (application quits unexpectedly before even showing its window).

It seems the versions I found on this forum do not work for me.

Judging from kernel logs kext loads fine.

 

Thanks!

There should be a link somewhere in the DSDT - Vanilla SpeedStep thread. Please note that it has been renamed recently, to eh... what was it. VoodooMonitor (I think).

 

Hi chief; I modded my DSDT (P5K-VM) using yours as a guide. Everything seems fine except for sleep; It goes to sleep but it wakes up by itself right after, USB devices need to be replugged and CMOS get reseted (I had this CMOS problem before adding SBUS and EC devices, but the computer was able to sleep). In the system log says "wake reason = UHC5 EHC1 HDEF EC EHC2".

Both boards (VM and Pro) are quite similar at least their DSDTs, so I guess might not be so difficult to find out the problem.

Could you suggest me how to track it?

Thanks!

 

Another thing; if I use your CPU definition secction (using my own CST and PSS tables) I get +10 degree temps. Probably CSTates are not loading.

 

Just in case you want to have a look I attach my DSDT:

I need a starting point. One where sleep worked, your pre-patch copy of the dsdt.dsl for example.

[spanakorizo]

Chief, here is my ioreg, that u asked

spanakorizo.ioreg.zip

p.s: your inbox is full, i tried to send u that reboot with no openhaltrestart and Device (EC) {} now works

but i put it back, because u said not to remove it yet

 

I named the model through smbios.plist :P5K PRO. Is it ok or u named it also through somewhere else?

[parcival39]

Master Chief, comprehension question

 

I would like to use GPU Power Management.

It is enough to have LegacyAGPM.kext, or needs one also your LegacyACPI_SMC_PP.kext.

I have working pss tables in the DSDT file.

 

thx

 

parcival

[Master Chief]

Chief, here is my ioreg, that u asked

spanakorizo.ioreg.zip

p.s: your inbox is full, i tried to send u that reboot with no openhaltrestart and Device (EC) {} now works

but i put it back, because u said not to remove it yet

Thanks. I'll clean it up right away. Done!

 

I named the model through smbios.plist :P5K PRO. Is it ok or u named it also through somewhere else?

Plain P5K PRO – I don't even have a smbios.plist

[Master Chief]

Master Chief, comprehension question

 

I would like to use GPU Power Management.

It is enough to have LegacyAGPM.kext, or needs one also your LegacyACPI_SMC_PP.kext.

I have working pss tables in the DSDT file.

 

thx

parcival

Both. And please note that we might need to add/change stuff later on. Still testing some things here.

[Beerkex'd]

I would like to use GPU Power Management.

It is enough to have LegacyAGPM.kext, or needs one also your LegacyACPI_SMC_PP.kext.

 

You may need to add your video cards device ID to LegacyAGPM.kext.

[Master Chief]

DSDT v2.9 has been released today! – See attachments in post #3.

 

We're now one step closer to a real MacPro3,1 Here's what I removed this time:

 

Phase 1:

 

OperationRegion: SMRG

Field: SMRG,

Method: SCMD, SBYT, WBYT, WWRD, RSBT, RBYT, RWRD, RBLK, WBLK

 

 

Phase 2:

 

OperationRegion: RAMW and IOB2

Field: RAMW and IOB2

Method: ISMI, GNVS, SNVS, GMAX, GMDX, GCAX, GCDX

 

Phase 3:

 

Method: _DSM from all UHCn Devices.

 

Plus a few new comments – mostly for the new GB board thread – and.. well have a look at one of the included diff files

[ZGT]

Thanks !!!!!!!

[aliab]

Hello MasterChief

 

first thank you for for your great job about DSDT,you make things going further!

i 've managed to resolve the auto sleep on P5W DH Deluxe

 

Checklist:

1) Inserting a CD/DVD makes auto sleep work (be it slow).

2) Disconnecting the drive from the motherboard makes auto sleep work.

 

both of the above workarounds work for this board and the dvd player is plugged to JMB363 sata (in fact no matter where it is plugged)

 

Let's have a look at the new code i have sampled using the documentation datasheet n° 307013.

 

 

// Newly added: MAP - Address Map Register (ICH7-307013.pdf / page 509).

OperationRegion (MAP, PCI_Config, 0x90, One)

Field (MAP, ByteAcc, NoLock, Preserve)

{

MV, 2,

, 3,

SMS, 2

}

 

// Newly added: PCS - Port Control and Status Register (ICH7-307013.pdf / page 509).

OperationRegion (PCS, PCI_Config, 0x92, 0x02)

Field (PCS, ByteAcc, NoLock, Preserve)

{

P0E, 1,

P1E, 1,

P2E, 1,

P3E, 1,

P0P, 1,

P1P, 1,

P2P, 1,

P3P, 1,

}

 

i am stuck as i do not understand exactly how to include in my dsdt ?

DSDT.dsl.zip

 

any suggestion would be very useful for me to get further

[747]

Thanks again Master Chief!

 

I've again just copied your dsdt.aml into my root and booted with no problems...

 

Sorry for the dumb question, but I currently have seven kexts installed in /System/Library/Extensions that I grabbed from your P5K_PRO_Extra_Extensions file - are any of these now redundant with this latest dsdt?

 

Also, I'm confused about the case of dsdt.aml - shouldn't it be DSDT.aml?

 

cheers!

[spanakorizo]

Chief, i noticed something, i dont know if it is because of the smbus or the agpm but Benchmarks are lower

this (as i saw in the results) is because of the CI,OpenGL results

for example with my own DSDT (not a lot of edits:power states,sleep,Sata/USB devices) i get 7100

with your method i get 5200

would u like to post your geekbench(x64) results?

i'm OC-->3.0GHZ and 4GB Ram

CPU Q6600

 

I know that u gave a lot of time in DSDT stuff, i just post my experience so we can discuss it

thanks again for your work on this.

 

(I tested a lot by removing LegacyKexts, but the overall score was the same (not more than 5300), so the OpenGL perfomance decrease maybe comes through the DSDT.

I also tried graphicsEnabler boot method,gfx strings etc for the 8800GT)

[Master Chief]

Thanks !!!!!!!

Great. One more happy "customer"

 

Hello MasterChief

<snip />

 

any suggestion would be very useful for me to get further

I am swamped by requests for help, almost literally, so you will have to wait for now.

 

Thanks again Master Chief!

I've again just copied your dsdt.aml into my root and booted with no problems...

 

Sorry for the dumb question, but I currently have seven kexts installed in /System/Library/Extensions that I grabbed from your P5K_PRO_Extra_Extensions file - are any of these now redundant with this latest dsdt?

 

Also, I'm confused about the case of dsdt.aml - shouldn't it be DSDT.aml?

 

cheers!

You are welcome. And please follow the directions in post #3 because I made two files, one for each directory. You may have to add others but this forum won't let me see you sig while replying... but now I know and. You are in fact using a P5K PRO board and thus the files should work for you when put in the proper directories.

 

Oh, and lower case it is yes.

 

Chief, i noticed something, i dont know if it is because of the smbus or the agpm but Benchmarks are lower

this (as i saw in the results) is because of the CI,OpenGL results

for example with my own DSDT (not a lot of edits:power states,sleep,Sata/USB devices) i get 7100

with your method i get 5200

would u like to post your geekbench(x64) results?

i'm OC-->3.0GHZ and 4GB Ram CPU Q6600

 

I know that u gave a lot of time in DSDT stuff, i just post my experience so we can discuss it

thanks again for your work on this.

 

(I tested a lot by removing LegacyKexts, but the overall score was the same (not more than 5300), so the OpenGL perfomance decrease maybe comes through the DSDT.

I also tried graphicsEnabler boot method,gfx strings etc for the 8800GT)

That is interesting. FYI: My hack scores 5400 @2.5GHz with the 32 bits version – sorry, I don't have a 64 bit version anymore. Just the free version.

 

And having lots of backup versions gives you the ability to go back until you found what it is that made this go bad. Educated guess: It is either graphics card related or due the fact that you now load more kexts.

 

UPDATE: I just remembered something; restart didn't work for me under Leopard, not until I replaced the modified boot file from ChameleonSM file with a vanilla one. Then Restart works here. Guess what.. the very same bug slipped into the new boot files.

[parcival39]

Chief, i noticed something, i dont know if it is because of the smbus or the agpm but Benchmarks are lower this (as i saw in the results) is because of the CI,OpenGL results

for example with my own DSDT (not a lot of edits:power states,sleep,Sata/USB devices) i get 7100 with your method i get 5200 would u like to post your geekbench(x64) results?

i'm OC-->3.0GHZ and 4GB Ram CPU Q6600

 

With geekbench(x32) i have likewise no problems. I use all hacks from Master Chief.

My hack scores 7193 @3.0GHz. CPU Q6700

 

parcival

[spanakorizo]

With geekbench(x32) i have likewise no problems. I use all hacks from Master Chief.

My hack scores 7193 @3.0GHz. CPU Q6700

 

parcival

your score is ok, i get 6500 in geekbench(x32) but with 4GB or ram (u have 8?)

something conflicts or by somehow decreases perfomance of GFX with chief's dsdt

more testing to come

(yesterday i even flashed the 8800GT to a Quadro FX3700!)

[parcival39]

Problems with sleep. Please help Master Chief.

 

Version 2.4 deep sleep (To hear no any FAN), but no reboot

Version 2.5 - 2.8 FAN from GPU run with high speed in sleep modus.

Version 2.9 no sleep, a possible cause your change with UHCx

 

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

 

What is here wrong?

Thanks for your time and work.

 

parcival

[Master Chief]

Problems with sleep. Please help Master Chief.

 

Version 2.4 deep sleep (To hear no any FAN), but no reboot

Version 2.5 - 2.8 FAN from GPU run with high speed in sleep modus.

Version 2.9 no sleep, a possible cause your change with UHCx

 

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

 

What is here wrong?

Thanks for your time and work.

parcival

Remember that this is a P5K PRO thread, and that things thus might break for people with other boards. No matter how close they are.

 

Now the solution: Start by adding the _DSM bits back into your DSDT (copy/past from a previous version would do) while I check the diff for you. Ok. _PTS is responsible for sleep – hence the name Prepare To Sleep – and the only two changes I've made in this Method between v2.4 and v2.5 are:

 

		Store (Arg0, \_SB.PCI0.LPCB.EC.ECSS) // Newly added for EC support.
	G3HT () // Newly added for EC support.

You can simply comment them out and restart to see if sleep works again. If yes then you've found the spot where it fails for your board. If not... then you might be in for a lot more testing.

[parcival39]

		Store (Arg0, \_SB.PCI0.LPCB.EC.ECSS) // Newly added for EC support.
		 G3HT () // Newly added for EC support.

You can simply comment them out and restart to see if sleep works again. If yes then you've found the spot where it fails for your board. If not... then you might be in for a lot more testing.

 

Thanks for your assistance, i will test it.

A question still (I want to learn something here).

Why are the "device-id" no longer necessary in UHCx with your version 2.9?

 

parcival

[kdawg]

@ Master Chief,

 

At what point did you no longer require OpenHaltRestart.kexd? It looks like you were originally using it but at some point you were able to drop it? I'm trying figure out at what it was that let you eliminate it.

 

Thanks for the great contributions.

[Master Chief]

Thanks for your assistance, i will test it.

A question still (I want to learn something here). Why are the "device-id" no longer necessary in UHCx with your version 2.9?

 

parcival

I don't know for sure but I am not willing to go back a few versions to check it for you. You may if you want, but I'm done with it. This is starting to take too much time anyway.

 

@ Master Chief,

 

At what point did you no longer require OpenHaltRestart.kexd? It looks like you were originally using it but at some point you were able to drop it? I'm trying figure out at what it was that let you eliminate it.

 

Thanks for the great contributions.

Thanks, but please read post #96 and #136.

 

Next up!

I got an interesting PM from down under Australia (thank you keeza) about Bonjour. Reminding me about the need for ifconfig en0 promisc to get Bonjour going without a Realtek network adapter/kext or a little script. Enter a new target! I quickly checked a few things and found this.

 

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>

aka IOInterfaceFlags (Number: 0x8863)

 

versus

 

en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST>

aka IOInterfaceFlags (Number: 0x8963)

 

That triggered me to read the: "Intel® I/O Controller Hub 8/9/10 and 82566/82567/82562V Software Developer’s Manual" where I found the Receive Control Register - RCTL (0x100). See attachments for a small part of the manual.

 

But there is more to it... because read this snippet taken from the ICH9R-316972.pdf (section 12.1.2 / page 412) datasheet:

 

Device ID — RO. This is a 16-bit value assigned to the Intel® ICH9 Gigabit LAN controller. The field may be auto-loaded from the NVM word 0Dh during initialization time depending on the "Load Vendor/Device ID" bit field in NVM word 0Ah.

 

Hello? Now think for a moment about LegacyYukon2.kext because all this kext does is to trick the OS into thinking it to be something else. Making me wonder if changing the NVM registers would make it work without the formentioned kext That I tell you is one of my next targets, if I only had some time for it.

[kdawg]

UPDATE: I just remembered something; restart didn't work for me under Leopard, not until I replaced the modified boot file from ChameleonSM file with a vanilla one. Then Restart works here. Guess what.. the very same bug slipped into the new boot files.

Pardon for not completely understanding. So you replaced an older ChameleonSM boot file with the more current version (vanilla) of Chameleon?

3) What boot loader are you using?

– I am using Chameleon v1.0.12 with a patched /boot file.

If my memory serves me right ChameleonSM patched boot file enabled the use of smbios.plist. Correct?

 

Guess what.. the very same bug slipped into the new boot files.

But then you also say the new version has the bug? What version of Chameleon are you using 2.0 r658 or did you revert back to v1.0.12 (vanilla)?

 

Thanks again.

[Master Chief]

Pardon for not completely understanding. So you replaced an older ChameleonSM boot file with the more current version (vanilla) of Chameleon?

 

If my memory serves me right ChameleonSM patched boot file enabled the use of smbios.plist. Correct?

 

But then you also say the new version has the bug? What version of Chameleon are you using 2.0 r658 or did you revert back to v1.0.12 (vanilla)?

 

Thanks again.

I can restart Leopard 10.5.8 with Chameleon v1.0.11 but not with ChameleonSM aka v1.0.12 and also not with any of the later Chameleon v2 versions. That I find a very strange coincidence.

 

p.s. ChameleonSM injects SMBIOS values from com.apple.Boot.plist not smbios.plist The result is however the same as Chameleon v2 (well almost).

[Master Chief]

The first set of changes for DSDT v3.0 are done. No more:

				Method (_PRT, 0, NotSerialized)
			{
				If (PICM)
				{
					Return (AR02)
				}

				Return (PR02)
			}

But this:

				Method (_PRT, 0, NotSerialized)
			{
				Return (Package (0x04) // New: Previously AR02
				{
					Package (0x04) { 0xFFFF, Zero, Zero, 0x10 },
					Package (0x04) { 0xFFFF,  One, Zero, 0x11 },
					Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 },
					Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 }
				})
			}

Which is cleaner and much easier to read – with everything n one spot.

 

Removed items: PR00, AR00, PR02, AR02, PR04, AR04, PR05, AR05, PR06, AR06, PR07, AR07, PR08, AR08, PR09, AR09, PR01 and AR01

 

Removed Methods: RBPE, RWPE, RDPE, WBPE, WWPE, WDPE, RWDP and RPME

Note: You can remove everything in this block, starting with Scope (_SB) { and ending with }

 

I still have to do more pruning and thus no file yet (wait for the announcement later this week).

[Beerkex'd]

Thanks.

 

Are you saying to replace all instances (AR00-AR09) of Method (_PRT) with your new code, or only replace AR02 and delete the rest?

 

It will be nice to be able to use the Marvell LAN without a legacy kext. I already tried simply patching the device ID in DSDT to that of a 88E8053, but I could never get it to work. So I'm looking forward to see how you deal with it.

[Master Chief]

Thanks.

 

Are you saying to replace all instances (AR00-AR09) of Method (_PRT) with your new code, or only replace AR02 and delete the rest?

What I did was to remove PR00 through PR09 and I simply used the data from AR00-AR09 for Method _PRT (each one is different). After that I also removed the AR00-AR09 blocks.

 

It will be nice to be able to use the Marvell LAN without a legacy kext. I already tried simply patching the device ID in DSDT to that of a 88E8053, but I could never get it to work. So I'm looking forward to see how you deal with it.

Yeah. I also tried to patch the device ID's. No go. I even went as far as flashing my BIOS – which bricked the darn thing so I gave up. This one should be better (requires a ton of reading though).

[Beerkex'd]

Heh, I can't visualize it from your words, I'll wait till I can see it first hand.

 

Good luck with the Marvell LAN.

 

While we're on the subject I'm going to sneak this one in...I've been using this fix by Krazubu since he posted it here a long time ago. Here is what it looks like in my DSDT now, with some of your code added to it:

 

Key:

Black: original DSDT code

Orange: Krazubu

Blue: El Jefe

 

			Device (P0P9)
		{
			Name (_ADR, 0x001C0005)
[color="#48D1CC"]				OperationRegion (PCTL, PCI_Config, 0x48, 0x04)
			Field (PCTL, ByteAcc, NoLock, Preserve)
			{
						Offset (0x01), 
				HPGE,   1, 
						Offset (0x02), 
						Offset (0x03), 
						Offset (0x04)
			}

			OperationRegion (PSTS, PCI_Config, 0x8C, 0x04)
			Field (PSTS, ByteAcc, NoLock, Preserve)
			{
						Offset (0x02), 
				PMES,   1, 
						Offset (0x04)
			}

			Method (_INI, 0, NotSerialized)
			{
				If (LNotEqual (BPHP, 0x05))
				{
					Store (One, HPGE)
				}
			}
[/color]
			Method (_PRW, 0, NotSerialized)
			{
				Return (GPRW (0x09, 0x04))
			}

			Method (_PRT, 0, NotSerialized)
			{
				If (PICM)
				{
					Return (AR09)
				}

				Return (PR09)
			}

[color="#FF8C00"]				Device (GIGE)
			{
				Name (_ADR, Zero)
				OperationRegion (GPIO, SystemIO, 0x0800, 0x06)
				Field (GPIO, ByteAcc, NoLock, Preserve)
				{
					GO01,   8, 
					GO02,   8, 
					GO03,   8, 
					GO04,   8, 
					GO05,   8, 
					GP9,	1
				}

				Name (_PRW, Package (0x02)
				{
					0x09, 
					0x03
				})
				Method (EWOL, 1, NotSerialized)
				{
					If (LEqual (Arg0, One))
					{
						Or (GP9, One, GP9)
					}
					Else
					{
						And (GP9, Zero, GP9)
					}

					If (LEqual (Arg0, GP9))
					{
						Return (Zero)
					}
					Else
					{
						Return (One)
					}
				}
			}[/color]
		}

 

Also, for reference:

http://www.projectosx.com/forum/index.php?showtopic=60

 

Should I just keep it the way it is or is there any advantage to changing the whole thing so that it matches yours?

 

/EDIT 01/11-2009

 

I never got a reply to this post but for the benefit of others who are using Krazubu's fix in their DSDT - it is perfectly safe to replace it with Master Chief's method, the 88E8056 keeps working in the same way as before.