Contribute
Register

MSI GS70 Development Thread

Status
Not open for further replies.
ayilm1 said:
I'll have to check out your repo. I really liked your Haswell PNLF patch. Never would have thought to use RWeverything. I'll have to have a play around with it as it seems insanely powerful. Being able to load up the fixed SSDTs is a must since 95% of the graphics code is contained in there. And I'm not a huge fan of the idea of going through the whole thing bit by bit.
Click to expand...

There is no problem loading patched SSDTs...

Yessir I am, thank you kindly for that as well.
Click to expand...

You might also check that you're getting the required notifies into the AC adapter. They usually originate from EC queries or GPE events. But if those are not happening or if they are aborting, then the battery manager may never see them. You can use the debug version of ACPIBatteryManager to see if they are received in a timely manner (or at all). See ACPIACAdapter::message for more info. That member function is called in response to a Notify on the AC adapter object...

On the topic of graphics, what's PCIe hotplug like under Mac OS? Can the _ON_ / _OFF methods be called within the same session, or is it one or the other?
Click to expand...

Don't know for sure... But from what I've heard, things get weird (eg. hard crash) if you call _OFF in the middle of things. The drivers attached tend to get confused and crash...
 
RehabMan said:
There is no problem loading patched SSDTs
Click to expand...

Sorry I should have added 'reliably'. They're all really quite bloated.

RehabMan said:
You can use the debug version of ACPIBatteryManager to see if they are received in a timely manner (or at all). See ACPIACAdapter::message for more info. That member function is called in response to a Notify on the AC adapter object
Click to expand...

Oh excellent, I'll take a look into it.

RehabMan said:
Don't know for sure... But from what I've heard, things get weird (eg. hard crash) if you call _OFF in the middle of things. The drivers attached tend to get confused and crash...
Click to expand...

That's hilarious and unfortunate at the same time. I might have to think of something else. Is Clover able to do user defined ACPI patching at boot? If I'm being a bit vague, the objective is to NOT disable the nvidia card permanently. External displays (of course) are routed through the card so the plan is to enable it as needed but a reboot isn't that inconvenient. So perhaps it can be initialized through a custom entry at boot.

Edit:

Actually now that I think about it. There could just be two DSDTs; one with _OFF called, one without; and a custom entry can be defined to switch between the two.
 
Alright so things have got a little interesting now. I took out PNOT and the power supply switches correctly. I also went ahead and fixed HDEF and HPET and audio works fine. The last thing to do was disable the discrete GPU. I tried the usual process of calling _OFF from the _INI and _WAK methods, and the graphics stayed put.

Code: 
Method (_OFF, 0, Serialized)  // _OFF: Power Off
        {
            \RMDT.PUSH("START")
            \RMDT.PUSH("ESGX(SSDT)")
            \_SB.PCI0.LPCB.EC.ESGX (Zero)
            
            If (LEqual (CTXT, Zero))
            {
                \RMDT.PUSH("1")
                
                If (LNotEqual (GPRF, One))
                {
                    \RMDT.PUSH("2")
                    Store (VGAR, VGAB)
                }


                Store (One, CTXT)
            }
            SGOF ()
            \RMDT.PUSH("SGOF Complete")
            \RMDT.PUSH("END")
        }

So I went and put a "START" and "END" into _OFF and it never ends. There's an SGOF() call at the end of _OFF so I moved that to the top and the NVIDIA disables correctly at the expense of artefacts on the display and loss of sleep functionality (Reboot on wake, sounds like invalid memory access).

So I dug a little deeper and added outputs to "\_SB.PCI0.LPCB.EC.ESGX (Zero)". Not sure why this method altering something in the EC but this whole thing's a mess so it's no surprise. The ESGX method is below.

Code: 
Mutex (SG6M, 0x00)
            Method (ESGX, 1, NotSerialized)
            {
                \RMDT.PUSH("ESGX(DSDT)")
                Acquire (SG6M, 0xFFFF)
                \RMDT.PUSH("MutexAcquired")
                If (LEqual (Arg0, Zero))
                {
                    \RMDT.PUSH("If1")
                    Store (Zero, ESGI)
                    \RMDT.PUSH("ESGI_Stored")
                    Store (One, ESGO)
                    \RMDT.PUSH("ESGO_Stored")
                    Store (Zero, ESGN)
                    \RMDT.PUSH("ESGN_Stored")
                }


                If (LEqual (Arg0, One))
                {
                    \RMDT.PUSH("If2")
                    Store (One, ESGI)
                    Store (Zero, ESGO)
                    Store (Zero, ESGN)
                }


                If (LEqual (Arg0, 0x02))
                {
                    \RMDT.PUSH("If3")
                    Store (Zero, ESGI)
                    Store (Zero, ESGO)
                    Store (One, ESGN)
                }
                \RMDT.PUSH("ReleasingMutex")
                Release (SG6M)
                \RMDT.PUSH("ExitESGX")
            }

This method never exits. The mutex declared at the top is acquired without any issues, and it branches into "If1". But then it stops.

Next I took out each of the registers being stored to (ESG(I/O/N), and the procedure exits successfully. Sleep also works correctly but there are still artefacts on the display.

The funny thing is, I can't even read out of these registers by doing \RMDT.P2("ESGI", ESGI). So either the mutex isn't doing its job, or the opregion address is wrong and causing a segfault (ha! like that can happen).
 
Okay... So I just added "\RMDT.P2 ("ESGI: ", ESGI)" to the battery _STA method to see if I could access these at all and it reads fine. So I think there is an issue with the mutex.
 
ayilm1 said:
Alright so things have got a little interesting now. I took out PNOT and the power supply switches correctly. I also went ahead and fixed HDEF and HPET and audio works fine. The last thing to do was disable the discrete GPU. I tried the usual process of calling _OFF from the _INI and _WAK methods, and the graphics stayed put.

Code: 
Method (_OFF, 0, Serialized)  // _OFF: Power Off
        {
            \RMDT.PUSH("START")
            \RMDT.PUSH("ESGX(SSDT)")
            \_SB.PCI0.LPCB.EC.ESGX (Zero)
            
            If (LEqual (CTXT, Zero))
            {
                \RMDT.PUSH("1")
                
                If (LNotEqual (GPRF, One))
                {
                    \RMDT.PUSH("2")
                    Store (VGAR, VGAB)
                }


                Store (One, CTXT)
            }
            SGOF ()
            \RMDT.PUSH("SGOF Complete")
            \RMDT.PUSH("END")
        }

So I went and put a "START" and "END" into _OFF and it never ends. There's an SGOF() call at the end of _OFF so I moved that to the top and the NVIDIA disables correctly at the expense of artefacts on the display and loss of sleep functionality (Reboot on wake, sounds like invalid memory access).

So I dug a little deeper and added outputs to "\_SB.PCI0.LPCB.EC.ESGX (Zero)". Not sure why this method altering something in the EC but this whole thing's a mess so it's no surprise. The ESGX method is below.

Code: 
Mutex (SG6M, 0x00)
            Method (ESGX, 1, NotSerialized)
            {
                \RMDT.PUSH("ESGX(DSDT)")
                Acquire (SG6M, 0xFFFF)
                \RMDT.PUSH("MutexAcquired")
                If (LEqual (Arg0, Zero))
                {
                    \RMDT.PUSH("If1")
                    Store (Zero, ESGI)
                    \RMDT.PUSH("ESGI_Stored")
                    Store (One, ESGO)
                    \RMDT.PUSH("ESGO_Stored")
                    Store (Zero, ESGN)
                    \RMDT.PUSH("ESGN_Stored")
                }


                If (LEqual (Arg0, One))
                {
                    \RMDT.PUSH("If2")
                    Store (One, ESGI)
                    Store (Zero, ESGO)
                    Store (Zero, ESGN)
                }


                If (LEqual (Arg0, 0x02))
                {
                    \RMDT.PUSH("If3")
                    Store (Zero, ESGI)
                    Store (Zero, ESGO)
                    Store (One, ESGN)
                }
                \RMDT.PUSH("ReleasingMutex")
                Release (SG6M)
                \RMDT.PUSH("ExitESGX")
            }

This method never exits. The mutex declared at the top is acquired without any issues, and it branches into "If1". But then it stops.

Next I took out each of the registers being stored to (ESG(I/O/N), and the procedure exits successfully. Sleep also works correctly but there are still artefacts on the display.

The funny thing is, I can't even read out of these registers by doing \RMDT.P2("ESGI", ESGI). So either the mutex isn't doing its job, or the opregion address is wrong and causing a segfault (ha! like that can happen).
Click to expand...

If your _OFF method directly or indirectly touches EC registers, it is possible that _INI is called prior to _REG for the EC. In which case, EC registers are unavailable and will cause abort. In that case, it is best to call _OFF from EC's _REG. See ACPI spec for more information on _REG and EC availability.
 
Hmm... But in that case, wouldn't it fail at 'Acquire'? The console output shows:

START
ESGX(SSDT)
ESGX(DSDT)
IF1

I'll give it a go anyway. I was just about to remove the mutex but that's pretty brutal. There's no _INI for the EC. Is it safe to just toss one in?

scratch that. I need to learn to read properly.
 
ayilm1 said:
Hmm... But in that case, wouldn't it fail at 'Acquire'?
Click to expand...

No. It would fail when unavailable EC registers are accessed.
 
Yep, so that makes it execute the whole method. But now the NVIDIA stays active; just with no kext loaded. Artefacts also remain. Sleep does however work. I might try moving it back to _INI and commenting out the mutex, however brutal that is.

Edit: That did jack.
 
There you go.

Disabled has

Store (Zero, ESGI)
Store (Zero, ESGO)
Store (Zero, ESGN)

Commented out.
 

Attachments

  • Archive.zip
    860.9 KB · Views: 111
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top