Jump to content

Master Chief's P5K PRO ACPI Warfare


VegasKarma
 Share

908 posts in this topic

Recommended Posts

@MC

 

In your C-states shouldn't this be 0x02?

 

           Name (_CST, Package (0x04)
           {
               0x03,
               Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},0x01,0x01,0x03E8}, 
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,    ,)},[color="#FF0000"]0x03[/color],0x01,0x01F4}, [color="#FF0000"]//<-- 0x02??[/color]
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,    ,)},0x03,0x55,0xFA}
           })

 

I was playing with a mashup of your method and FormerlyKnownAs's. The code below give me clear definition between the two sets of processors but slightly hotter temps. So I see cores appear at different multipliers i.e. (x6, x6, x7, x7)

    Scope (_PR)
   {
	Processor (CPU0, 0x00, 0x00000410, 0x06)
	{
		Method (_PSS, 0, NotSerialized)
		{
			Return (Package(0x03)
			{
				Package (0x06) { 0x00, 0x00, 10, 10, 0x00000822, 0 },
				Package (0x06) { 0x00, 0x00, 10, 10, 0x0000071E, 1 },
				Package (0x06) { 0x00, 0x00, 10, 10, 0x0000061A, 2 }
			})
		}

           Method (_PSD, 0, NotSerialized)
           {
               Return (Package (0x05) {0x05, 0x00, 0x00, 0xFC, 0x04})
           }

		Method (_CST, 0, NotSerialized)
		{
			Return (Package (0x02)
			{
				0x01, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x0000000000000000, 0x01, )}, 0x01, 0x9D, 0x03E8} 
			})
		}
	}

	Processor (CPU1, 0x01, 0x00000410, 0x06)
	{
		Alias (\_PR.CPU0._PSS, _PSS)
                       Alias (\_PR.CPU0._PSD, _PSD)
		Method (_CST, 0, NotSerialized)
		{
			Return (Package (0x04)
			{
				0x03, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x0000000000000000, ,)}, 0x01, 0x00, 0x03E8}, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x0000000000000414, ,)}, 0x02, 0x01, 0x01F4}, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x0000000000000415, ,)}, 0x03, 0x11, 0xFA} 
			})
		}
	}

	Processor (CPU2, 0x02, 0x00000410, 0x06)
	{
		Alias (\_PR.CPU0._PSS, _PSS)
                       Alias (\_PR.CPU0._PSD, _PSD)
		Alias (\_PR.CPU1._CST, _CST)
	}

	Processor (CPU3, 0x03, 0x00000410, 0x06)
	{
		Alias (\_PR.CPU0._PSS, _PSS)
                       Alias (\_PR.CPU0._PSD, _PSD)
		Alias (\_PR.CPU1._CST, _CST)
	}
}

 

When I consolidate C-states to the first CPU like yours I loose that independent multiplier definition. And see my x7 multiplier much less.

 

    Scope (_PR) // Processor scope (namespace).
   {
       Processor (CPU0, 0x00, 0x00000410, 0x06)
       {
           Name (_PSS, Package (0x03)
           {
               Package (0x06) { 0x00, 0x00, 10, 10, 0x00000822, 0 },
               Package (0x06) { 0x00, 0x00, 10, 10, 0x0000071E, 1 },
               Package (0x06) { 0x00, 0x00, 10, 10, 0x0000061A, 2 }
           })

           Name (_PSD, Package (0x05) {0x05, 0x00, 0x00, 0xFC, 0x04})

           Name (_CST, Package (0x04)
           {
               0x03,
               Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},0x01,0x01,0x03E8}, 
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,    ,)},0x02,0x01,0x01F4}, 
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,    ,)},0x03,0x55,0xFA}
               })
       }

       Processor (CPU1, 0x01, 0x00000410, 0x06)
       {
           Alias (\_PR.CPU0._PSS, _PSS)
           Alias (\_PR.CPU0._PSD, _PSD)
           Alias (\_PR.CPU0._CST, _CST)
       }

       Processor (CPU2, 0x02, 0x00000410, 0x06)
       {
           Alias (\_PR.CPU0._PSS, _PSS)
           Alias (\_PR.CPU0._PSD, _PSD)
           Alias (\_PR.CPU0._CST, _CST)
       }

       Processor (CPU3, 0x03, 0x00000410, 0x06)
       {
           Alias (\_PR.CPU0._PSS, _PSS)
           Alias (\_PR.CPU0._PSD, _PSD)
           Alias (\_PR.CPU0._CST, _CST)
       }
   }

Link to comment
Share on other sites

@MC

 

In your C-states shouldn't this be 0x02?

 

           Name (_CST, Package (0x04)
           {
               0x03,
               Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},0x01,0x01,0x03E8}, 
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000814,    ,)},[color="#FF0000"]0x03[/color],0x01,0x01F4}, [color="#FF0000"]//<-- 0x02??[/color]
               Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000815,    ,)},0x03,0x55,0xFA}
           })

Absolutely! Good catch – a failing last minute change. Thanks!

 

When I consolidate C-states to the first CPU like yours I loose that independent multiplier definition. And see my x7 multiplier much less.

I wouldn't know why, but I will try to figure it out – by adding a dummy _CST object under CPU2.

 

Edit: No change whatsoever with a dummy object. Not to mention that Apple DSDT's are using:

	Scope (\_PR.CPU1)
{
	Method (_CST, 0, NotSerialized)
	{
		Return (\_PR.CPU0._CST)
	}
}

So I don't think so. I mean it isn't using any _CST object on the second Processor definition block. That's why I removed it a while ago ;)

Link to comment
Share on other sites

Thanks man!; I apreciate the work you're doing!

I brought my P5K-VM dsdt to match yours; everything seems to work good for me, except sleep-wake-restart sequence (which hangs at the point you should see the BIOS boot screen).

No problem here, but my DSDT is optimized to work with OSXRestart.kext – see attachments in post #3

 

I got a question about:

 ... see post # 427

 

As I understand, this is to be able to auto-sleep your CD-DVD drive, isnt it? If so, would be possible to use the same kind of code to work in a drive hooked to the Jmicron IDE connector (present on the P5K-VM)?

 

I've tryed something like this:

Notify (\_SB.PCI0.P0P4.JMB0.IDE0, 0x81)

But didnt work so far...

No, unfortunately not. You may remove this code. And what exactly is the problem? The drive won't spin down for sleep?

 

A note for the P5K-VM:

One could delete the code for P0P devices addressed at 0x001C0001-3 as they dont appear in the IOReg, and probably they dont exist phisically either:

post-51637-1258801031_thumb.jpg

No! These are part of each ICH9 chip set. Even the ICH10 and older chipsets. And the minute people plug in something BOOM

 

Thanks ;)

 

So you removed GPRW? :D

Yes, because the _Sn data is static in Apple DSDT's and it isn't expecting a shift in S state.

Link to comment
Share on other sites

No problem here, but my DSDT is optimized to work with OSXRestart.kext – see attachments in post #3

 

Yes, Im using that kext too. But still restart breaks after sleep-wake

 

No, unfortunately not. You may remove this code. And what exactly is the problem? The drive won't spin down for sleep?

 

The problem is that the computer wont go to sleep by itself. I thought it might be the dvd drive...

 

 

No! These are part of each ICH9 chip set. Even the ICH10 and older chipsets. And the minute people plug in something BOOM

 

I see. But why they dont show in the IOreg then?, P5K-VM has two PCI-E slot less than the P5K-Pro so, wouldnt at least two ports not be there?

Link to comment
Share on other sites

I see. But why they dont show in the IOreg then?, P5K-VM has two PCI-E slot less than the P5K-Pro so, wouldnt at least two ports not be there?

Apple disable unused one in EFI, on our boards they aren't even if they are not used at all, check for example other apple ioregs, especial those on macmini or macbook....

Link to comment
Share on other sites

Yes, Im using that kext too. But still restart breaks after sleep-wake

Ok, Just asking, to be sure. Are other P5K-VM users here having a similar restart problem?

 

The problem is that the computer wont go to sleep by itself. I thought it might be the dvd drive...

That might indeed be a problem. You could disconnect the drive to see if that solves it. At least then you know for sure?

 

I see. But why they dont show in the IOreg then?, P5K-VM has two PCI-E slot less than the P5K-Pro so, wouldnt at least two ports not be there?

You should only see active ports with ioreg and IORegistryExplorer, where some sort of connection has been established. And not only by inserting a PCI(E) card, because P0P8 won't show up until I enable the PATA device in my BIOS. Just to name one example

 

p.s. I ripped another 365 bytes, not by removing features or functionality, but by re-writing some of the code.

Link to comment
Share on other sites

Ok, Just asking, to be sure. Are other P5K-VM users here having a similar restart problem?

 

DB1 confirmed he has the same problem; we are using same files.

 

That might indeed be a problem. You could disconnect the drive to see if that solves it. At least then you know for sure?

Seems the DVD drive wasnt the problem after disable the jmicron controller from BIOS

 

 

You should only see active ports with ioreg and IORegistryExplorer, where some sort of connection has been established. And not only by inserting a PCI(E) card, because P0P8 won't show up until I enable the PATA device in my BIOS. Just to name one example

 

Is not exactly the case for me:

post-51637-1258812850_thumb.jpg

See P0P3; nothing is hooked there but still shows in the RegExplorer

and

post-51637-1258812913_thumb.jpg

P0P4 still there after disabling Jmicron controller, but P0P5 is gone (ethernet disabed)

 

Anyways, you've been reading the ICH9 spec sheets and I didnt so better I put the P0P code back into my dsdt.

Thanks again!

Link to comment
Share on other sites

Absolutely! Good catch – a failing last minute change. Thanks!

 

 

I wouldn't know why, but I will try to figure it out – by adding a dummy _CST object under CPU2.

 

Edit: No change whatsoever with a dummy object. Not to mention that Apple DSDT's are using:

	Scope (\_PR.CPU1)
{
	Method (_CST, 0, NotSerialized)
	{
		Return (\_PR.CPU0._CST)
	}
}

So I don't think so. I mean it isn't using any _CST object on the second Processor definition block. That's why I removed it a while ago :)

 

I see your logic.

Link to comment
Share on other sites

...

Is not exactly the case for me: See P0P3; nothing is hooked there but still shows in the RegExplorer

That's the "PCI Express Port 1" which is a root domain controller. Look for PCITOPLevel in ioreg -l output. There's your answer (the other ports are linked to it).

 

and ... P0P4 still there after disabling Jmicron controller, but P0P5 is gone (ethernet disabed)

 

Anyways, you've been reading the ICH9 spec sheets and I didnt so better I put the P0P code back into my dsdt.

Thanks again!

And P0P4 should not be visible when the Jmicron controller is disabled in the BIOS. However, you may have forced a connection from your DSDT. And you could check this by looking at the ioreg output, because it should not be there without anything connected to it. Or there's something else active. Just to give you some ideas.

 

p.s. You may want to renamed these, because it was confusing the heck out of me :)

 

I see your logic.

You agree? Should I read this as a confirmation?

Link to comment
Share on other sites

That's the "PCI Express Port 1" which is a root domain controller. Look for PCITOPLevel in ioreg -l output. There's your answer (the other ports are linked to it).

 

 

And P0P4 should not be visible when the Jmicron controller is disabled in the BIOS. However, you may have forced a connection from your DSDT. And you could check this by looking at the ioreg output, because it should not be there without anything connected to it. Or there's something else active. Just to give you some ideas.

 

p.s. You may want to renamed these, because it was confusing the heck out of me ;)

 

 

You agree? Should I read this as a confirmation?

 

Well now that I know why you set it up that way I want to look into it more and run a few tests, that's all. I prefer your method because it's shorter and simpler.

 

I like your approach to DSDT patching. Shorter, simpler and more logical. Do you actally notice an improvement in boot times?

Link to comment
Share on other sites

Well now that I know why you set it up that way I want to look into it more and run a few tests, that's all. I prefer your method because it's shorter and simpler.

 

I like your approach to DSDT patching. Shorter, simpler and more logical. Do you actally notice an improvement in boot times?

Yes. It is two seconds quicker. Look at the spinner below the Apple logo, and notice a slight improvement before your sceen is initialized. That's where the improved should be noticed.

 

DB1 confirmed he has the same problem; we are using same files.

In that case additional testing is required (for P5K VM users). I understand that it hangs at a point where your BIOS screen should be displayed, which makes me wonder if OSXRestart.kext is still loaded as the same thing happens when I unload the kext and try to restart from the Apple menu.

 

You might want to try: sudo kextunload OSXRestart.kext before entering sleep, and use: sudo kextload OSXRestart.kext after sleep, before doing a restart, to see if that helps. And restart-after-sleep fails in both 32 and 64 bit mode?

 

Update: I think to have found something – the keyboard controller (state) might be the culprit. Please check the attached update of OSXRestart.kext No more keyboard controller hacks – now using the FACP table data (from my hack).

 

Let's look at the suspicious code:

while (inb(0x64) & 0x02);

What if bit 1 is never set after sleep, or the (Super IO) controller hangs? This way it will never reach the next line of code, and thus it can't initiate the restart (by writing 0xfe in the keyboard controller). It is a bit of a wild guess, I admit, but this might be it.

 

Update II: I started a new topic for OSXRestart.kext which can be found here where I will attach updates and add comments when available/needed.

 

Attachment removed (after 25 download) because new versions can be found by following the provided link.

Link to comment
Share on other sites

Let's look at the suspicious code:
while (inb(0x64) & 0x02);

What if bit 1 is never set after sleep, or the (Super IO) controller hangs? This way it will never reach the next line of code, and thus it can't initiate the restart (by writing 0xfe in the keyboard controller). It is a bit of a wild guess, I admit, but this might be it.

 

Indeed! You hit it!

I did just a fast sleep-wake-restart test and it worked just fine. I'll run more tests later today, but I guess thats that.

Thanks a bunch!! We owe you some beers

Link to comment
Share on other sites

Indeed! You hit it!

I did just a fast sleep-wake-restart test and it worked just fine. I'll run more tests later today, but I guess thats that.

Thanks a bunch!! We owe you some beers

Good to hear. Thank you for your confirmation. Let's hope this is it. Would be nice :)

 

Let's see if I can reset the controller in my DSDT. That might be even better.

Link to comment
Share on other sites

Let's look at the suspicious code:
while (inb(0x64) & 0x02);

What if bit 1 is never set after sleep, or the (Super IO) controller hangs? This way it will never reach the next line of code, and thus it can't initiate the restart (by writing 0xfe in the keyboard controller). It is a bit of a wild guess, I admit, but this might be it.

It works here too, thank you so much! :)

Link to comment
Share on other sites

It works here too, thank you so much! :D

Thank you for your confirmation.

 

That's the bit of magic we needed, works perfect for me. P5K VM users are in your debt.

 

Thanks again :rolleyes:

Thanks. We finally nailed it.

 

Had a bit if a déjà vu – looked into it before, but I was unable to solve this puzzle at that time. Hoping that FireWire and TSSTcorp DVD drives can also be fixed one day soon. Keeping my fingers crossed.

Link to comment
Share on other sites

Here we go, Gigabyte's DSDT based on your (Master Chief) DSDT research.

My board is EP45-UD3LR (ICH10R).

 

Should be useful for all Gigabyte boards, IMO.

 

Size with GFX and HDEF only 94KB. :D

 

You should fork off a new thread for Gigabyte boards to keep this one on topic. But I'm sure it'll get lots of traffic if you modell it off of Master Chief's work.

Link to comment
Share on other sites

Here we go, Gigabyte's DSDT based on your (Master Chief) DSDT research.

My board is EP45-UD3LR (ICH10R).

 

Should be useful for all Gigabyte boards, IMO.

Good work stickpin. Your mobo and mine (GA-EP45-DS3L) are almost identical and your DSDT converted from Masterchief's is further advanced than my own. I will have a look through it, thanks. When I report back, I will do so in the Gigabyte DSDT fix thread. Regards :(

Link to comment
Share on other sites

 Share

×
×
  • Create New...