Jump to content
VegasKarma

Master Chief's P5K PRO ACPI Warfare

908 posts in this topic

Recommended Posts

Hi Master Chief,

 

As already reported, when using the SBUS patch, it tries to load the kexts com.apple.driver.AppleMikeyDriver and com.apple.driver.AppleMikeyHIDDriver.

 

These are not needed and report an error when they load, yet they remain loaded.

 

Is it possible to disable loading them when using SMBUS (which would also disable the logged error)?

 

Thanks!

Reported where? I must have missed it. Not to mention that this specific code part is commented out, so that can't trigger a kext load.

 

 

Hi Master chief,

I see that you add this method in the cpu declaration :

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

is it specific to your cpu ?

 

Barnum

No, and I kindly point you to the ACPI specification (link in post #3) where you can read everything you want to know about this sort of Methods. No need to ask here :)

 

...

 

But only for those who get that error on boot, also to show that it has the same effect with full apple copy/paste.

No need for thanks since this was discovered long time before you started to play with DSDT.

Never seen anything about it. But probably because I usually do things my way anyway, most of the time the hard way, because this way I learn stuff. I didn't exactly learn to walk in one day either so...

 

I always remarked when you have a good idea, like was with _INI method(also recommended by a friend), and the _PRT stuff is interesting...

Thanks, but there is no need for 'battles' anymore. We know what we know and want to share stuff. Right? Like I say, move on forward either with or without my help :D

 

I'm also happy to see that you started to add back stuff from SIOR in the place where they belong SBUS, waiting for the day when you will remove EC device since is useless...

I didn't. Really. And I won't remove EC because I need it (for my notebook).

 

I totally disagree with your new methods, you are going, like other ODM/OEM's who dosen't fallow ACPI specs, to create more confusion then clearing something. IMHO DSM is good enough for what we use, and also almost all knows what it does, what you will do create new methods for other stuff we have to inject? Try to keep stuff in the known area(and as they are defined in specs)...you already got negative results/reports on this.

Uhm. Well. I don't see a need for unused arguments, and thus I simply removed them.

 

Now. About Method DTGP because that isn't even mentioned in the ACPI specifications. Not even once, and thus changing methods like DTGP is a non-issue. Also no word about adding new methods, not even one single word and thus that too is really a non-issue. You may dislike it, but that's as far as it goes.

 

And yes, I might add a new method or change one or more previously introduced methods. Pretty obvious of course, for a developer trying to move forward.

Share this post


Link to post
Share on other sites
Advertisement
No, and I kindly point you to the ACPI specification (link in post #3) where you can read everything you want to know about this sort of Methods. No need to ask here :thumbsup_anim:

 

Thanks, I read the spec and I modify your code to this because I have a core 2 duo not quad :thumbsup_anim:

 

            Method (_PSD, 0, NotSerialized)
           {
               Return (Package (0x05)
               {
                   0x05,
                   0x00,
                   0x00,
                   0xFC,
                   [b]0x02[/b]
               })
           }

 

Barnum

Share this post


Link to post
Share on other sites
Thanks, I read the spec and I modify your code to this because I have a core 2 duo not quad :)

 

...

 

Barnum

Well done! Doing stuff yourself is much more rewarding isn't it ;)

Share this post


Link to post
Share on other sites
Well done! Doing stuff yourself is much more rewarding isn't it :)

 

Terribly rewarding !

 

Method (_PSD, 0, NotSerialized)
{
Return (Package (0x05)
{
0x05,
0x00,
0x00,
[b][color="#ff0000"]0xFC,[/color][/b]
0x02
})
}

 

In red 'OSPM Coordinate' - "When OSPM coordinates, the platform may

require that OSPM transition ALL (0xFC) or ANY ONE (0xFD) of the processors belonging to the domain into a particular target state."

 

So by using 0xFC rather than 0xFD OSPM will treat all cores as 1. Surely you should be using 0XFD?

 

D

Share this post


Link to post
Share on other sites
[...] So by using 0xFC rather than 0xFD OSPM will treat all cores as 1. Surely you should be using 0XFD?

 

D

IMHO it's the exact opposite, and to prove it, take a peek at the Example in the ACPI Spec rev. 4.0 page 329, where it says "[...] OSPM will be required to coordinate the P-state transitions between the two processors and can initiate a transition on either processor to cause both to transition to the common target P-state." and the value in the example code is 0xFD.

Share this post


Link to post
Share on other sites

I have a Ti 1394a firewire card.When I insert it to the motherboard.Still presented "FireWire runtime power conservation disabled. (2)"

 

I think DSDT.aml 3.1 can not fix this firewire card.Built-in VendorID firewire had fix.

 

 

Can you tell me how to fix Ti 1394a firewire card.

 

It in motherboard's PCI 1 position.

 

In kernel.log,I get the following information:"FireWire (OHCI) TI ID 8020 PCI now active, GUID 00e0003c1670018f; max speed s400."

 

At ioregistryexplorer :"PCI104c,8020@1"

PCI104c_8020_1.tiff

Share this post


Link to post
Share on other sites
IMHO it's the exact opposite, and to prove it, take a peek at the Example in the ACPI Spec rev. 4.0 page 329, where it says "[...] OSPM will be required to coordinate the P-state transitions between the two processors and can initiate a transition on either processor to cause both to transition to the common target P-state." and the value in the example code is 0xFD.

 

That is a kind of hazy statement isn't it. I've read it three times and still not sure what value it should be.

Share this post


Link to post
Share on other sites
IMHO it's the exact opposite, and to prove it, take a peek at the Example in the ACPI Spec rev. 4.0 page 329, where it says "[...] OSPM will be required to coordinate the P-state transitions between the two processors and can initiate a transition on either processor to cause both to transition to the common target P-state." and the value in the example code is 0xFD.

 

OK Granted I think you're right ... but surely users with unsupported CPU's (like me!) shouldn't be letting SW manage the transition?! and if anything that value should be 0xFE (HW_ALL)!

 

D.

Share this post


Link to post
Share on other sites
That is a kind of hazy statement isn't it. I've read it three times and still not sure what value it should be.

Well, I'll stick to my statement until someone proves otherwise. :(

OK Granted I think you're right ... but surely users with unsupported CPU's (like me!) shouldn't be letting SW manage the transition?! and if anything that value should be 0xFE (HW_ALL)!

 

D.

If I'm right, and our CPUPM kext strictly follows the ACPI Specification, there should be no problems, because we (our ACPI tables) tell OSPM what and how to do, but let's wait for a really experienced guy's reply on this.

Share this post


Link to post
Share on other sites
who's that then ??

My guess is Master Chief, the source this snippet for our DSDTs. :)

No one wants to plug it in and try it out?

It looks like you do. :P Anyways, I will, as soon as Chief replies on this thing.

Share this post


Link to post
Share on other sites

And here's the Chief with his reply... right after waking up. Take a look at this little snippet:

        Method (_PSD, 0, NotSerialized)
       {
           If (And (CFGD, 0x01000000))  // The default value = 0x01000007!
           {
               If (And (TYPE, 0x0800))  // Unfortunately for us, bit 11 is not set!
               {
                   Return (Package (0x01)
                   {
                       Package (0x05)
                       {
                           0x05, 
                           0x00, 
                           0x00, 
                           0xFE, 
                           NCPU
                       }
                   })
               }

               Return (Package (0x01)   // And this we end up here.
               {
                   Package (0x05)
                   {
                       0x05, 
                       0x00, 
                       0x00, 
                       [color="#FF0000"]0xFC[/color], 
                       NCPU
                   }
               })
           }

           Return (Package (0x01)       // But nowadays here – due to all removals.
           {
               Package (0x05)
               {
                   0x05, 
                   0x00, 
                   0x00, 
                   [color="#FF0000"]0xFC[/color], 
                   NCPU
               }
           })
       }
   }

And yes ladies and gentlemen, this code was copied from a PK5 Pro's cpu[1/2/3/4]pm.dsl Experimenting? Coffee first for the Chief now :)

Share this post


Link to post
Share on other sites
And yes ladies and gentlemen, this code was copied from a PK5 Pro's cpu[1/2/3/4]pm.dsl Experimenting? Coffee first for the Chief now :)

 

Given - however a P5K was born to run Windows**

Share this post


Link to post
Share on other sites
Given - however a P5K was born to run Windows**

I absolutely agree with you here, but I wasn't done with my reply – note the coffee first part of it – because let's first look at a few facts taken from the ACPI specification:

 

1) This optional object provides P-state control cross logical processor dependency information to OSPM.

2) This object cannot be found in any of the SSDT's I have in my possession (13) which I think are quite a few.

 

The preliminary conclusion therefor should be that adding this object is totally useless to OS X. Right? But wait a minute, why don't we give it a try first? And so I did. And in fact I am still using it! Why would that be? Am I delusional or am I running experiments to rule out errors?

 

Now you change that value and see what it does, if anything. Here it seems to have some sort of influence on how my boards/CPU P-States are working. In other words; give it a try and let me know what you see. This way we all are learning something. Right?

 

Edit: And I did not tell anyone about this little experiment, because that might blur peoples observation. I want something that more people can reproduce. So I didn't tell you. Just to let you know why. And both me and my buddy from down under Australia (keeza) think that we haven't seen the bottom of C-State, and possibly not even for P-States – this due to the fact that we don't even know what this P-Stepper (Step2_0) data really does (still working on it).

Share this post


Link to post
Share on other sites
I have a Ti 1394a firewire card.When I insert it to the motherboard.Still presented "FireWire runtime power conservation disabled. (2)"

 

I think DSDT.aml 3.1 can not fix this firewire card.Built-in VendorID firewire had fix.

 

Can you tell me how to fix Ti 1394a firewire card.

 

It in motherboard's PCI 1 position.

 

In kernel.log,I get the following information:"FireWire (OHCI) TI ID 8020 PCI now active, GUID 00e0003c1670018f; max speed s400."

 

At ioregistryexplorer :"PCI104c,8020@1"

Ok. Note the PCI104c,8020@1 because that's the address you need to use in your DSDT. As in:

				Device (FRWC) // Newly added device
			{
				Name (_ADR, 0x00010000)
				Name (_GPE, 0x19)

				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
					{
						"fwhub",
						Buffer (0x02)
						{
							0x00, 0x00, 0x00, 0x00
						}
					}, Local0)

					MCDP (Arg2, RefOf (Local0))
					Return (Local0)
				}
			}

And under Scope (_GPE) you add:

			Method (_L19, 0, NotSerialized) // Newly added for FireWire support.
		{
			Notify (\_SB.PCI0.PCIB.FRWC, 0x00)
		}

Share this post


Link to post
Share on other sites

IMPORTANT UPDATE

 

The latest Apple update (10.6.2) is troubling me. In fact I cannot even startup with DSDT V3.2 anymore so I have to figure out what the problem is. Make sure you have at least DSDT V3.0 in your / as dsdt-v30.aml so that you can go back to this still working version.

 

Now I'm about to test DSDT V3.1 with OS X 10.6.2 (No problems here. Is just fine).

 

Update: Users of CPU-i should first upgrade to VoodooMonitor or you end up like me, with only one CPU core showing up in CPU-i. Thanks to cparm for providing the file!

 

WhatTheBEEP.png

 

And here's the working one:

 

VoodooMonitoreWorkswithOSX1062.png

Share this post


Link to post
Share on other sites

Hi List, Chief

With 10.6.2 sound problem (DSDT V3.1). Did someone also see?

 

Possibly an idea?

 

thx

parcival

 

Kernel log:

Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 == commonDSPArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAEngine.cpp" at line 239 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 1698 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != createAudioEngines ( fPathMap_aDriverInstance )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 203 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 == commonDSPArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAEngine.cpp" at line 239 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 1698 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != createAudioEngines ( fPathMap_aDriverInstance )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 203 goto Exit

Share this post


Link to post
Share on other sites
Hi List, Chief

With 10.6.2 sound problem (DSDT V3.1). Did someone also see?

 

Possibly an idea?

 

thx

parcival

 

Kernel log:

Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 == commonDSPArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAEngine.cpp" at line 239 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 1698 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != createAudioEngines ( fPathMap_aDriverInstance )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 203 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 == commonDSPArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAEngine.cpp" at line 239 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 1698 goto Exit
Nov 10 09:12:37 StefanMacPro kernel[0]: Sound assertion "0 != createAudioEngines ( fPathMap_aDriverInstance )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDADriver.cpp" at line 203 goto Exit

Not here. I only have these two, like before with 10.6.1:

 

...Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler

...Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989

 

What kext do you use for sound? Did you patch anything for this in your DSDT? Sorry, can't check way past my bed time Tomorrow another day.

Share this post


Link to post
Share on other sites
Not here. I only have these two, like before with 10.6.1:

 

...Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler

...Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989

 

What kext do you use for sound? Did you patch anything for this in your DSDT? Sorry, can't check way past my bed time Tomorrow another day.

 

Hi Chief

Thanks for your fast answer. Does your sound work?

With the old AppleHDA my sound works again.

I have LegacyAppleHDAHardwareConfigDriver.kext, LegacyHDAController.kext and LegacyHDAPlatformDriver.kext for ACL888.

 

Is someone here, at which ACL888 with 10.6.2 works?

 

parcival

Share this post


Link to post
Share on other sites

Update.

I changed my DSDT somewhat and have only LegacyHDA.kext.

Now sound (ACL888) works also with original AppleHDA from 10.6.2.

In the kernel logfile i have now only this error message.

 

 Sound assertion "0 == pciVendorProductID" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 2682 goto Exit

 

Last update to ACL888 and 10.6.2.

I added the key "PCIVendorDeviceID" in LegacyHDA.kext still and now

i have no more error message (AppleHDA) in kernel logfile. ;)

Share this post


Link to post
Share on other sites
Update.

I changed my DSDT somewhat and have only LegacyHDA.kext.

Now sound (ACL888) works also with original AppleHDA from 10.6.2.

In the kernel logfile i have now only this error message.

 

 Sound assertion "0 == pciVendorProductID" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 2682 goto Exit

 

Last update to ACL888 and 10.6.2.

I added the key "PCIVendorDeviceID" in LegacyHDA.kext still and now

i have no more error message (AppleHDA) in kernel logfile. :(

 

Would you mind detailing what you changed via DSDT and precisely where you inserted PCIVendorDeviceID into LegacyHDA?

 

Thanks

Share this post


Link to post
Share on other sites

kdawg, no problem

 

HDEF part in DSDT

           Device (HDEF) // Patched for audio.
           {
               Name (_ADR, 0x001B0000)

               // Newly added.
               OperationRegion (HDCS, PCI_Config, 0x54, 0x04) // Power Management Control/Status (ICH9R-3169722.pdf / 17.1.19 / page 664).
               Field (HDCS, DWordAcc, NoLock, Preserve)
               {
                       ,   15, 
                   PMES,   1
               }

               Method (_PRW, 0, NotSerialized)
               {
                   Return (Package (0x02)
                   {
                       0x0D, 
                       0x06
                   })
               }

               // Newly added Method.   
               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x0A)
                       {
                           "built-in",
                           Buffer (One)
                           {
                               0x01
                           },

                           "codec-id",
                           Buffer (0x04)
                           {
                               0x88, 0x08, 0xEC, 0x10
                           },

                           "layout-id",
                           Buffer (0x04)
                           {
                               0x78, 0x03, 0x00, 0x00
                           },

                           "device-type",
                           Buffer (0x0F)
                           {
                               "Realtek ALC888"
                           },

                           "PinConfigurations",
                           Buffer (0x28)
                           {
                               /* 0000 */    0x10, 0x90, 0xA1, 0x01, 0x20, 0x90, 0xA1, 0x02,
                               /* 0008 */    0x80, 0x30, 0x81, 0x01, 0x90, 0x40, 0x21, 0x02,
                               /* 0010 */    0x30, 0x40, 0x11, 0x01, 0x40, 0x40, 0x01, 0x01,
                               /* 0018 */    0x50, 0x60, 0x01, 0x01, 0x60, 0x20, 0x01, 0x01,
                               /* 0020 */    0x70, 0x61, 0x4B, 0x01, 0xA0, 0x01, 0xCB, 0x01
                           }
                       }, Local0)
                   MCDP (Arg2, RefOf (Local0))
                   Return (Local0)
               }
           }

 

 

LegacyHDA.kext part

	   <key>CodecAddressFilterArray</key>
           <array>
               <dict>
                   <key>CodecAddressMask</key>
                   <data>
                   AQAAAA==
                   </data>
                   <key>LayoutID</key>
                   <integer>16392</integer>
                   [b]<key>PCIVendorDeviceID</key> <- [/b]Read from original AppleHDA.kext  
[b]                    <integer>282987200</integer>[/b]
               </dict>
               <dict>
                   <key>CodecAddressMask</key>
                   <data>
                   AQAAAA==
                   </data>
                   <key>LayoutID</key>
                   <integer>0</integer>
                  [b] <key>PCIVendorDeviceID</key> [/b][b]<- [/b]Read from original AppleHDA.kext  
[b]                    <integer>282987200</integer>[/b]
               </dict>
           </array>

 

Here is my LegacyHDA.kext. Those is however only for ACL888.

LegacyHDA.kext.zip

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×