Jump to content

Matthew L.

Matthew L.

Member Since 26 Jul 2006
Offline Last Active Jul 30 2011 11:09 AM

Posts I've Made

In Topic: Master Chief's P5K PRO ACPI Warfare

09 November 2009 - 11:14 PM

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.

In Topic: Master Chief's P5K PRO ACPI Warfare

09 November 2009 - 07:01 PM

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


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.

In Topic: Master Chief's P5K PRO ACPI Warfare

09 November 2009 - 04:49 PM

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


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.

In Topic: DSDT fixes for Gigabyte boards

08 November 2009 - 12:28 PM

[...] Please note that we went on removing this because I don't need this (neither did mm67) though your board seems to need it. [...]

Hmm... Unfortunately power still doesn't go off when going to S5. As I've been reading some info in the ACPI spec and the ICH9 datasheet I've found that _PRW and _PSW are responsible per device for choosing the correct device state depending on global state. It looks like that OS X thinks USB devices should wake up the sleeping (S5) system, therefore it doesn't cut power and leaves the USB in D2 (or D1? and it stays like this till the next power on's USB re-init by the BIOS), even if the corresponding function in the BIOS is off. It should be the USBW's value that does this, shouldn't it?
P.S: I have the Wake for Ethernet network access option turned off in Energy Saver, does that really wake the PC occasionally, and can it make a difference in this kind of problem?

In Topic: DSDT fixes for Gigabyte boards

07 November 2009 - 09:09 PM

I'm not sure it's so vital what value is as long as the two values match.

Method (_L1A, 0, NotSerialized) // <--this 1A should match
			Notify (\_SB.PCI0.PCIB.FRWR, 0x00)
			Notify (\_SB.PWRB, 0x02)

Device (FRWR)
					Name (_ADR, 0x00070000)
					Name (_GPE, 0x1A) // <--this 1A

Well, yeah, I've noticed this similarity in all of the devices that are part of the GPE scope, but I wasn't sure you can just grab any unused value and use it. Thanks! :)

[...] this is most likely due to changes to Method _WAK so please check this method once more, and step by step [...]

Original _WAK method:
Method (\_WAK, 1, NotSerialized)    {        Store (0xFF, DBG1)        If (LEqual (Arg0, 0x03))        {            Store (0x8F, SCP)        }        If (LEqual (Arg0, 0x04))        {            If (LEqual (OSFL, 0x00))            {                If (LEqual (OSFX, 0x03))                {                    Store (0x59, SMIP)                }                Else                {                    Store (0x58, SMIP)                }            }            If (LEqual (OSFL, 0x01))            {                Store (0x56, SMIP)            }            If (LEqual (OSFL, 0x02))            {                Store (0x57, SMIP)            }            If (LEqual (OSFX, 0x03))            {                Store (0x59, SMIP)            }        }        If (LEqual (Arg0, 0x01)) {}        If (OSFL)        {            Notify (\_SB.PWRB, 0x02)        }        Else        {            If (LEqual (RTCW, 0x00))            {                Notify (\_SB.PWRB, 0x02)            }        }        Notify (\_SB.PCI0.USB0, 0x00)        Notify (\_SB.PCI0.USB1, 0x00)        Notify (\_SB.PCI0.USB2, 0x00)        Notify (\_SB.PCI0.USB3, 0x00)        Notify (\_SB.PCI0.USB4, 0x00)        Notify (\_SB.PCI0.USB5, 0x00)    }

Current method:
Method (_WAK, 1, NotSerialized)    {        Store (Zero, \_SB.PCI0.LPCB.EC.ECSS)        \_SB.PCI0.SBUS.ENAB ()        Store (0xFF, DBG1)        Notify (\_SB.PWRB, 0x02)        PNOT ()        Notify (\_SB.PCI0.UHC1, Zero)        Notify (\_SB.PCI0.UHC2, Zero)        Notify (\_SB.PCI0.UHC3, Zero)        Notify (\_SB.PCI0.UHC4, Zero)        Notify (\_SB.PCI0.UHC5, Zero)        Notify (\_SB.PCI0.UHC6, Zero)        Notify (\_SB.PCI0.POP2, Zero)        Return (Package (0x02)        {            Zero,             Zero        })    }

As I see there shouldn't be anything that does anything like this. (SCP is about thermal policy and SMIP is about the SMBus controller's interrupt pin.)
So are there any users whose keyboards/mice LEDs light up as they press a key after the computer has been shut down by Snow Leo? (Negatives are important too, so please, report, but in a non-polluting way, so make your posts have something else in them.)

@ FormerlyKnownAs: You've been trying dropssdt=no and enabling c-states + EIST in your bios while your model was MacPro3,1 right? Then if that's the case, the only (maybe) relevant differences in our DSDTs are the PNOT method and the defined PDCns, nothing else (except the defined frequencies and power). You may need a wizard to help you, because it really should work. :( (BTW, how was it working earlier?)
© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy