Jump to content

Master Chief's P5K PRO ACPI Warfare

VegasKarma

By VegasKarma,
in Patches

 Share
908 posts in this topic

Recommended Posts

Master Chief
Master Chief
Posted
Posted
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.

Link to comment
Share on other sites
barnum
barnum
Posted
Posted
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

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
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

Link to comment
Share on other sites
Matthew L.
Matthew L.
Posted
Posted
[...] 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.

Link to comment
Share on other sites
ZGT
ZGT
Posted
Posted

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

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
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.

Link to comment
Share on other sites
FKA
FKA
Posted
Posted
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.

Link to comment
Share on other sites
Matthew L.
Matthew L.
Posted
Posted
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.

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted

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

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
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).

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
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)
		}

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted

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

Link to comment
Share on other sites
parcival39
parcival39
Posted
Posted

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

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
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.

Link to comment
Share on other sites
parcival39
parcival39
Posted
Posted
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

Link to comment
Share on other sites
parcival39
parcival39
Posted
Posted

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. ;)

Link to comment
Share on other sites
kdawg
kdawg
Posted
Posted
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

Link to comment
Share on other sites
parcival39
parcival39
Posted
Posted

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

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...