Contribute
Register

MSI GS70 Development Thread

Status
Not open for further replies.
ayilm1 said:
No change commenting it out unfortunately. But here's something interesting. Even AFTER commenting everything in ESGX out, the stub still came up in System Profiler. However doing the same but calling it from _INI instead (the currently best working configuration), gets rid of it completely. I think there is something inherently different about running it from _REG. Perhaps the PEG and root ports aren't initialised at this point so when they are, PEG just _INIs a disabled device? I'm not sure. I'm going to try lastly to move it back to _INI in its current state and leave _ON in _PTS. Though I think I may have already tried this.
Click to expand...

Not sure what you were 'commenting out'...

It could be that other regions the code accesses aren't ready. I would use ACPIDebug to trace the _REG (and its arguments), so you can see which regions become available and in what order...
 
Yeah, sorry that wasn't terribly clear. Code always helps:

Code: 
Method (ESGX, 1, NotSerialized)
            {
                Acquire (SG6M, 0xFFFF)
                /*
                If (LEqual (Arg0, Zero))
                {
                    Store (Zero, ESGI)
                    \RMDT.P2 ("If1 : ESGI", ESGI)
                    Store (One, ESGO)
                    \RMDT.P2 ("If1 : ESGO", ESGO)
                    Store (Zero, ESGN)
                    \RMDT.P2 ("If1 : ESGN", ESGN)
                }


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


                If (LEqual (Arg0, 0x02))
                {
                    Store (Zero, ESGI)
                    \RMDT.P2 ("If3 : ESGI", ESGI)
                    Store (Zero, ESGO)
                    \RMDT.P2 ("If3 : ESGO", ESGO)
                    Store (One, ESGN)
                    \RMDT.P2 ("If3 : ESGN", ESGN)
                }*/
                Release (SG6M)
            }

I know brutal. So here are the cases:

Not commented out and called from _INI
  • Card doesn't turn off
  • Kexts load
  • LED Orange
  • Orange after sleep

Commented out and called from _INI
  • Card turns off
  • Doesn't show up in System Profiler
  • LED white
  • LED orange after sleep

Not commented out and called from _REG
  • Card partially turns off
  • Shows up in System Profiler as 'Display' with no kexts loaded
  • LED white
  • LED orange after sleep

Commented out and called from _REG
  • Same as above, on the surface at least



It could be that other regions the code accesses aren't ready. I would use ACPIDebug to trace the _REG (and its arguments), so you can see which regions become available and in what order...
Click to expand...
I'll do that now.
 
ayilm1 said:
Yeah, sorry that wasn't terribly clear. Code always helps:

Code: 
Method (ESGX, 1, NotSerialized)
            {
                Acquire (SG6M, 0xFFFF)
                /*
                If (LEqual (Arg0, Zero))
                {
                    Store (Zero, ESGI)
                    \RMDT.P2 ("If1 : ESGI", ESGI)
                    Store (One, ESGO)
                    \RMDT.P2 ("If1 : ESGO", ESGO)
                    Store (Zero, ESGN)
                    \RMDT.P2 ("If1 : ESGN", ESGN)
                }


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


                If (LEqual (Arg0, 0x02))
                {
                    Store (Zero, ESGI)
                    \RMDT.P2 ("If3 : ESGI", ESGI)
                    Store (Zero, ESGO)
                    \RMDT.P2 ("If3 : ESGO", ESGO)
                    Store (One, ESGN)
                    \RMDT.P2 ("If3 : ESGN", ESGN)
                }*/
                Release (SG6M)
            }
Click to expand...

The ESGX in the DSDT in Final looks like this:
Code: 
            Method (ESGX, 1, NotSerialized)
            {
                Acquire (SG6M, 0xFFFF)
                If (LEqual (Arg0, Zero)) {}
                If (LEqual (Arg0, One))
                {
                    Store (One, ESGI)
                    Store (Zero, ESGO)
                    Store (Zero, ESGN)
                }

                If (LEqual (Arg0, 0x02))
                {
                    Store (Zero, ESGI)
                    Store (Zero, ESGO)
                    Store (One, ESGN)
                }

                Release (SG6M)
            }

Why did you add the extra code for Arg0==0 case?
 
RehabMan said:
The ESGX in the DSDT in Final looks like this:
Code: 
            Method (ESGX, 1, NotSerialized)
            {
                Acquire (SG6M, 0xFFFF)
                If (LEqual (Arg0, Zero)) {}
                If (LEqual (Arg0, One))
                {
                    Store (One, ESGI)
                    Store (Zero, ESGO)
                    Store (Zero, ESGN)
                }

                If (LEqual (Arg0, 0x02))
                {
                    Store (Zero, ESGI)
                    Store (Zero, ESGO)
                    Store (One, ESGN)
                }

                Release (SG6M)
            }
Click to expand...

Yeah sorry, I noticed that before. However the results are the same even if all the branches are removed.

Why did you add the extra code for Arg0==0 case?
Click to expand...

I didn't, the 'Stores' are just missing and the compiler left the branch in.

As for the _REG availability, only SystemIO and EC are made accessible, in that order.
 
ayilm1 said:
Yeah sorry, I noticed that before. However the results are the same even if all the branches are removed.



I didn't, the 'Stores' are just missing and the compiler left the branch in.

As for the _REG availability, only SystemIO and EC are made accessible, in that order.
Click to expand...

Try with the original code. Use ACPIDebug to determine where/if the code is aborting...

Detailed analysis of the code may be necessary. Especially if it is conditional on _OSI (directly or indirectly), or other system state.

You could also compare code path when called from _INI vs. _REG.

Oh one other thing... in order to measure the effect and determine whether it is disabled or not, use a meter (Kill-a-watt) to measure power draw from the wall (remove the battery and use only AC power). There are too many variables to rely on battery time left...
 
ayilm1 said:
...
As for the _REG availability, only SystemIO and EC are made accessible, in that order.
Click to expand...

So everything should be accessible at EC availability.
 
RehabMan said:
Oh one other thing... in order to measure the effect and determine whether it is disabled or not, use a meter (Kill-a-watt) to measure power draw from the wall (remove the battery and use only AC power). There are too many variables to rely on battery time left...
Click to expand...

Wish I could, damn thing has a built in battery. Good call though. That being said, I tested after a clean boot with the same youtube video playing, twice. In both tests, calling PINI from _REG had about 2:10 on full charge and calling from _INI with the the first if branch commented out had about 3:30.

As for the ACPI debug. Here's the case for calling PINI from _REG. I'll do one for _INI next.

Code: 
kernel[0]: [ PCI configuration begin ]
kernel[0]: console relocated to 0x7fa0000000
kernel[0]: [ PCI configuration end, bridges 6, devices 13 ]
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x1, "Arg1: ", 0x1, }
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x3, "Arg1: ", 0x1, }
kernel[0]: ACPIDebug: { "OSYS @ _REG: ", 0x7d0, "OSVR @ _REG: ", 0x5, }
kernel[0]: ACPIDebug: "Entering ESGX"
kernel[0]: ACPIDebug: { "If1: ESGI: ", 0x0, }
kernel[0]: ACPIDebug: { "If1: ESGO: ", 0x1, }
kernel[0]: ACPIDebug: { "If1: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: GeForceSensors (pci1): [Fatal] unknown Kepler chipset           // FakeSMC is picking up the GPU
kernel[0]: GeForceSensors (pci1): [Error] unknown chipset, 0xffffffff
kernel[0]: ACPIDebug: "Exiting _REG"
kernel[0]: PEGP: Not usable

kernel[0]: ACPIDebug: { "If2: ESGI: ", 0x1, }
kernel[0]: ACPIDebug: { "If2: ESGO: ", 0x0, }
kernel[0]: ACPIDebug: { "If2: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: ACPIDebug: "Exiting _PTS"


kernel[0]: ACPIDebug: "Entering _WAK"
kernel[0]: ACPIDebug: { "OSYS @ _WAK: ", 0x7d0, "OSVR @ _WAK: ", 0x5, }
kernel[0]: ACPIDebug: "Entering ESGX"
kernel[0]: ACPIDebug: { "If1: ESGI: ", 0x0, }
kernel[0]: ACPIDebug: { "If1: ESGO: ", 0x1, }
kernel[0]: ACPIDebug: { "If1: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: Wake reason: PWRB (User)

And the DSL.
 

Attachments

  • DSDT(PEGP_disabled).zip
    36.5 KB · Views: 88
ayilm1 said:
Wish I could, damn thing has a built in battery.
Click to expand...

Unless it is glued down, they are usually pretty easy to remove.

Good call though. That being said, I tested after a clean boot with the same youtube video playing, twice. In both tests, calling PINI from _REG had about 2:10 on full charge and calling from _INI with the the first if branch commented out had about 3:30.
Click to expand...

A better way would be to look at InstantAmperage in ioreg.

As for the ACPI debug. Here's the case for calling PINI from _REG. I'll do one for _INI next.

Code: 
kernel[0]: [ PCI configuration begin ]
kernel[0]: console relocated to 0x7fa0000000
kernel[0]: [ PCI configuration end, bridges 6, devices 13 ]
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x1, "Arg1: ", 0x1, }
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x3, "Arg1: ", 0x1, }
kernel[0]: ACPIDebug: { "OSYS @ _REG: ", 0x7d0, "OSVR @ _REG: ", 0x5, }
kernel[0]: ACPIDebug: "Entering ESGX"
kernel[0]: ACPIDebug: { "If1: ESGI: ", 0x0, }
kernel[0]: ACPIDebug: { "If1: ESGO: ", 0x1, }
kernel[0]: ACPIDebug: { "If1: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: GeForceSensors (pci1): [Fatal] unknown Kepler chipset           // FakeSMC is picking up the GPU
kernel[0]: GeForceSensors (pci1): [Error] unknown chipset, 0xffffffff
kernel[0]: ACPIDebug: "Exiting _REG"
kernel[0]: PEGP: Not usable

kernel[0]: ACPIDebug: { "If2: ESGI: ", 0x1, }
kernel[0]: ACPIDebug: { "If2: ESGO: ", 0x0, }
kernel[0]: ACPIDebug: { "If2: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: ACPIDebug: "Exiting _PTS"


kernel[0]: ACPIDebug: "Entering _WAK"
kernel[0]: ACPIDebug: { "OSYS @ _WAK: ", 0x7d0, "OSVR @ _WAK: ", 0x5, }
kernel[0]: ACPIDebug: "Entering ESGX"
kernel[0]: ACPIDebug: { "If1: ESGI: ", 0x0, }
kernel[0]: ACPIDebug: { "If1: ESGO: ", 0x1, }
kernel[0]: ACPIDebug: { "If1: ESGN: ", 0x0, }
kernel[0]: ACPIDebug: "Exiting ESGX"
kernel[0]: Wake reason: PWRB (User)
Click to expand...

You will want to completely instrument the _OFF method (and all methods directly or indirectly called).
 
RehabMan said:
Unless it is glued down, they are usually pretty easy to remove.
Click to expand...

Too many damn screws haha.

RehabMan said:
A better way would be to look at InstantAmperage in ioreg.
Click to expand...

You are just full of surprises.

RehabMan said:
You will want to completely instrument the _OFF method (and all methods directly or indirectly called).
Click to expand...

Will do. I just wanted to do a quick skim with things I can access from the DSDT since _OFF and _ON are both stored in an SSDT. I think I found something though. The post will be up in a bit.
 
Okay so this is really interesting. Here's what happens right after PCI config begin:

Code: 
kernel[0]: [ PCI configuration begin ]
kernel[0]: console relocated to 0x7fa0000000
kernel[0]: [ PCI configuration end, bridges 6, devices 13 ]
kernel[0]: ACPIDebug: Version 0.1.0 starting
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x1, "Arg1: ", 0x1, }   // SystemIO becomes available
kernel[0]: ACPIDebug: "Entering _INI"          // Calling PINI from INI
kernel[0]: ACPIDebug: "Entering ESGX"        // ESGX never exits
kernel[0]: ACPIDebug: "Entering _REG"
kernel[0]: ACPIDebug: { "Arg0: ", 0x3, "Arg1: ", 0x1, }   // EC becomes available
kernel[0]: ACPIDebug: { "OSYS @ _REG: ", 0x7d0, "OSVR @ _REG: ", 0x5, }
kernel[0]: ACPIDebug: "Exiting _REG"

So when _OFF tries to access the EC region, it 'segfaults' (wrong term I know) because it's not available yet and the kernel stops running the code.

That's not the breakthrough though. The awesome thing is, all the code already works. I put the system to sleep and woke it back up in an attempt to capture the log. And on wake, the LED turned white and the display came on briefly before the system crashed. Although it doesn't seem to be in the log, I think the geforce drivers crashed when they couldn't find an endpoint to tie into. Therefore, there's nothing inherently wrong with the code, I'm just using it wrong.

I either need to find another place to call _OFF from after the EC region becomes available and before the PEGP is enumerated, or I need to bring forward the EC _REG call.

Is it legal to call '_REG (3,1)' from inside PINI, or is does it HAVE to be called by the OS? I'm still a bit hazy on the details.

Edit: actually, granted that it's possible, _REG(3,1) should probably be called in _INI since we don't want it executing every time PINI is run. Just on boot.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top