[SOLVED] wake causes freeze/panic in Dell 7577

B.A.C.H · Oct 14, 2018

here we go...

RehabMan · Oct 14, 2018

B.A.C.H said:
Dear RehabMan,

thank you for sticking with me!
It is quite evident, that I am very much outside of my comfort zone, but I am desperate to learn more and actually enjoy the process of troubleshooting, even though I keep banging my head against my own ignorance.
It is therefore best for me to move in microsteps and address one small issue at a time, before I cause any collateral damage by attempting to fix things that I don't understand.

I decided to tackle the graphics card first, and was very surprised that it is not disabled. I thought that inserting:

Code:

<dict> <key>Device</key> <string>NVidia</string> <key>Disabled</key> <false/> <key>Key</key> <string>class-code</string> <key>Value</key> <data> /////w== </data> </dict>

into Devices - AddProperties would do just that. If not, what is the point of this entry?

That disables the Nvidia graphics drivers (software associated with the graphics device), not the device itself.

Code:
I am reading your guide on actually disabling the discrete graphics card:
https://www.tonymacx86.com/threads/guide-disabling-discrete-graphics-in-dual-gpu-laptops.163772/

and I have:

1) Decompiled SSDT's (I had decompiled the DSDT)
2) Searched for _INI and _OFF and found that they are referenced in the same tables, namely DSDT, SSDT-2 and SSDT-12
3) Looked for any reference to a discrete device in those tables.
However here the problems start.

I expected to find something along the lines of:

Code:

Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (Zero, \_SB.PCI0.RP05.PEGP._ADR) }

as is the case in your guide, but instead I get:

SSDT-12:

Code:

Scope (\_SB.PCI0.GFX0) { Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (DID1, Index (TLPK, Zero)) Store (DID2, Index (TLPK, 0x02)) Store (DID3, Index (TLPK, 0x04)) Store (DID4, Index (TLPK, 0x06)) Store (DID5, Index (TLPK, 0x08)) Store (DID6, Index (TLPK, 0x0A)) Store (DID7, Index (TLPK, 0x0C)) Store (DID2, Index (TLPK, 0x0E)) Store (DID1, Index (TLPK, 0x0F)) Store (DID2, Index (TLPK, 0x11)) Store (DID3, Index (TLPK, 0x12)) Store (DID2, Index (TLPK, 0x14)) Store (DID4, Index (TLPK, 0x15)) Store (DID2, Index (TLPK, 0x17)) Store (DID5, Index (TLPK, 0x18)) Store (DID2, Index (TLPK, 0x1A)) Store (DID6, Index (TLPK, 0x1B)) Store (DID2, Index (TLPK, 0x1D)) Store (DID7, Index (TLPK, 0x1E)) }

That is the _INI for the IGPU, not Nvidia.

I am using a Clover patch to rename GFX0 to IGPU, why is there still a reference to GFX0?

Because you're looking at native tables in ACPI/origin.
Look at your patchmatic -extract output, and you'll see the effects of Clover hotpatch.

Code:
In SSDT-2 I only find code of the type:

Code:

Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (LTRX, LTRS) Store (OBFX, OBFS) }

Which, if I understand it correctly is referencing other methods?

Finally in DSDT there are many instances of _INI but the ones that I *think* are initialisations of devices take the form of:

Code:

scope (_SB.PCI0.xxx) { device (some_device) { body } }

Inside the body I find methods that look like the following one:

Code:

Method (_INI, 0, NotSerialized) // _INI: Initialize { If (CondRefOf (\_SB.PCI0.XHC.RHUB.INIR)) { ^RHUB.INIR () } }

But as far as I could tell no reference to a discrete graphics device...
I am sure the main problem I have is not being able to read the iasl disassembly correctly. Is there any general guide on reading/understanding iasl output?

Sorry for this somewhat lengthy post...
(I would attach the decompiled DSDT and SSDT's but I keep getting an error message)

You likely have no _INI for the Nvidia. It is not uncommon and is mentioned in the guide.
When there is no existing _INI, you simply add one in the same scope as _OFF (again, covered in the guide).

B.A.C.H · Oct 14, 2018

Dear RehabMan,

thank you a lot for your explanations, everything starts making a lot more sense to me now.
I thought that there might not be an _INI method for the Nvidia card, but I was not sure if it was me not recognising it (given my inexperience). As for the _OFF method, I found the following code in SSDT-2:

Code:

Method (_OFF, 0, Serialized)  // _OFF: Power Off
            {
                Store (0x55, TMP1)
                If (LEqual (TDGC, One))
                {
                    CreateField (TGPC, Zero, 0x03, GUPC)
                    If (LEqual (ToInteger (GUPC), One))
                    {
                        \_SB.PCI0.PEG0.PEGP.GC6I ()
                    }
                    ElseIf (LEqual (ToInteger (GUPC), 0x02))
                    {
                        \_SB.PCI0.PEG0.PEGP.GC6I ()
                    }
                }
                ElseIf (LGreater (OSYS, 0x07D9))
                {
                    Store (0x66, TMP1)
                    PGOF (Zero)
                    Store (Zero, _STA)
                }
            }

and SSDT-12

Code:

Method (_OFF, 0, Serialized)  // _OFF: Power Off
        {
            If (LEqual (CTXT, Zero))
            {
                Store (VGAR, VGAB)
                Store (One, CTXT)
            }

            PGOF (Zero)
        }

DSDT

Code:

If (LAnd (LEqual (RTD3, Zero), LEqual (PEWE, One)))
    {
        Scope (_SB.PCI0.RP12.PXSX)
        {
            PowerResource (PXP, 0x00, 0x0000)
            {
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Return (One)
                }

                Method (_ON, 0, NotSerialized)  // _ON_: Power On
                {
                }

                Method (_OFF, 0, NotSerialized)  // _OFF: Power Off
                {
                }
            }

            Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0
            {
                PXP
            })
        }
    }

But I am not sure if either of them is referencing the Nvidia card. I am inclined to say that the Nvidia-relevant code is in SSDT-12 because SSDT-12 seems to contain the graphics-related tables and has the same references as in your guide. That leads me to the following question:

What are CTXT, VGAR and VGAB?

Also, on a side note:
What does "CreateField" mean?
Is it allocating memory?

RehabMan · Oct 14, 2018

B.A.C.H said:
Dear RehabMan,

thank you a lot for your explanations, everything starts making a lot more sense to me now.
I thought that there might not be an _INI method for the Nvidia card, but I was not sure if it was me not recognising it (given my inexperience). As for the _OFF method, I found the following code in SSDT-2:

Code:

Method (_OFF, 0, Serialized) // _OFF: Power Off { Store (0x55, TMP1) If (LEqual (TDGC, One)) { CreateField (TGPC, Zero, 0x03, GUPC) If (LEqual (ToInteger (GUPC), One)) { \_SB.PCI0.PEG0.PEGP.GC6I () } ElseIf (LEqual (ToInteger (GUPC), 0x02)) { \_SB.PCI0.PEG0.PEGP.GC6I () } } ElseIf (LGreater (OSYS, 0x07D9)) { Store (0x66, TMP1) PGOF (Zero) Store (Zero, _STA) } }

and SSDT-12

Code:

Method (_OFF, 0, Serialized) // _OFF: Power Off { If (LEqual (CTXT, Zero)) { Store (VGAR, VGAB) Store (One, CTXT) } PGOF (Zero) }

DSDT

Code:

If (LAnd (LEqual (RTD3, Zero), LEqual (PEWE, One))) { Scope (_SB.PCI0.RP12.PXSX) { PowerResource (PXP, 0x00, 0x0000) { Method (_STA, 0, NotSerialized) // _STA: Status { Return (One) } Method (_ON, 0, NotSerialized) // _ON_: Power On { } Method (_OFF, 0, NotSerialized) // _OFF: Power Off { } } Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 { PXP }) } }

But I am not sure if either of them is referencing the Nvidia card. I am inclined to say that the Nvidia-relevant code is in SSDT-12 because SSDT-12 seems to contain the graphics-related tables and has the same references as in your guide. That leads me to the following question:

What are CTXT, VGAR and VGAB?

Also, on a side note:
What does "CreateField" mean?
Is it allocating memory?

As per guide, you first fine the _OFF method, then search for an _INI in the same scope. The scope is displayed in the MaciASL status bar when you click in the method (and you can look at the enclosing code as well).

Yes, you found the _OFF in SSDT-12.

B.A.C.H · Oct 14, 2018

I think I have applied the patch and disabled the Nvidia card, but I'm not sure. How would I verify it? IoRegistryExplorer?
There is still a Peg0 device in the registry. Does that mean, that I did not patch it correctly?

RehabMan · Oct 14, 2018

B.A.C.H said:
I think I have applied the patch and disabled the Nvidia card, but I'm not sure. How would I verify it? IoRegistryExplorer?
There is still a Peg0 device in the registry. Does that mean, that I did not patch it correctly?

Note the subtle change.
Before:

Screen Shot 2018-10-14 at 3.02.19 PM.png

After:

Your ACPI/patched content is wrong.
No need to place all SSDTs there... just put the one(s) that needed patches.

B.A.C.H · Oct 14, 2018

Note the subtle change.

You are a genius, sir!

Your ACPI/patched content is wrong.
No need to place all SSDTs there... just put the one(s) that needed patches.

I know... I noticed it only after posting it... sorry.

Next I will address the USB setup, but first I will need one ore more serious re-readings of your guides.
Thank you again!

B.A.C.H · Oct 16, 2018

Dear RehabMan

I have spent the last two days reading your fantastic guides on setting up the USB ports.

In accordance with your guides I made the following changes:

Applied the ACPI renames EHCX -> ECX
Applied the ACPI renames EC0 -> EC and H_EC -> for proper power management
Studied my port setup in IOReg and created my custom SSDT
Finally, I disabled the port patches in “KextsToPatch”

I hope that my USB setup is correct now.
IOReg only shows the ports I effectively need, but I have some questions regarding my current state:

I plan to replace my current wifi card with a compatible one (mini pcie). Will that affect my IOReg entries in XHC or does it use a different socket?
My laptop also has a thunderbolt3/usb-c port which, currently, I am not using (I have no devices to test it with and I am aware of the limitations concerning TB on Hacks anyway).
Will the usb-c part of it be deactivated by my SSDT or will it be handled by the OS as a Thunderbolt device exclusively (with its own distinct socket in IOReg)?
I have many kext patches which I am not sure I need. Where could I find some documentation for them? They are leftovers of previous attempts to solve my issues but I don’t like the idea of keeping (useless?) settings that I don’t understand. I copied them from discussions in the forum, but no direct explanation of what they do was provided.

But most importantly:

Sleep/wake is now working!
(disabling the Nvidia card did the trick)

Thank you for helping me out despite my complete inexperience! For absolute beginners like me it is very encouraging to meet somebody as knowledgeable as you who is also willing to help and listen to the same “noob questions” time and time again without just telling us where to go.

RehabMan · Oct 16, 2018

B.A.C.H said:
Applied the ACPI renames EHCX -> ECX

Nonsense. The hardware in your profile has no EHCI controller.

Applied the ACPI renames EC0 -> EC and H_EC -> for proper power management

Nonsense.
You must apply only one of the appropriate patches.
(if you rename two active objects to the same name at the same path, you will cause KP as it is not legal ACPI).
Plus your EC is named ECDV.

I hope that my USB setup is correct now.
IOReg only shows the ports I effectively need,

Your ioreg shows problems:
- UsbConnector value seem wrong. There should be 1:1 correspond between SSxx UsbConnector=3 and HSxx UsbConnector=3. I find 3x SSxx UsbConnector=3, but zero HSxx with UsbConnector=3.

I plan to replace my current wifi card with a compatible one (mini pcie). Will that affect my IOReg entries in XHC or does it use a different socket?

The BT will connect to the same HS04.

My laptop also has a thunderbolt3/usb-c port which, currently, I am not using (I have no devices to test it with and I am aware of the limitations concerning TB on Hacks anyway). Will the usb-c part of it be deactivated by my SSDT or will it be handled by the OS as a Thunderbolt device exclusively (with its own distinct socket in IOReg)?

You would need to test the USB part of it to know for sure. Some of the setups have some of the USB pins on TB3 directed to XHC.

I have many kext patches which I am not sure I need. Where could I find some documentation for them? They are leftovers of previous attempts to solve my issues but I don’t like the idea of keeping (useless?) settings that I don’t understand. I copied them from discussions in the forum, but no direct explanation of what they do was provided.

No need for any port limit patches since you're under the 15 port limit.
AppleBacklight patch not needed with AppleBacklightFixup.kext
External icons patch not needed.
AppleHDA patches not needed with AppleALC.kext.
Framebuffer patches are done via WhateverGreen injections instead of KextsToPatch.

Sleep/wake is now working!
(disabling the Nvidia card did the trick)

Great.
(that is a very common one...)
Hitting all the pinned threads and reading the FAQ is important.

B.A.C.H · Oct 17, 2018

Dear RehabMan,

RehabMan said:
Nonsense. The hardware in your profile has no EHCI controller.

True, there is only XHC! Stupid mistake.

RehabMan said:
Nonsense.
You must apply only one of the appropriate patches.
(if you rename two active objects to the same name at the same path, you will cause KP as it is not legal ACPI).
Plus your EC is named ECDV.

I found references in my DSDT to both EC0, and H_EC, so, while I am aware that in your guide you explicitly state that we should use one or the other, I was not sure (and still don't understand what they mean - at this point I guess that they are totally unrelated):

Code:

External (_SB_.PCI0.LPCB.H_EC.CHRG, DeviceObj)    // (from opcode)
    External (_SB_.PCI0.LPCB.H_EC.XDAT, MethodObj)    // 0 Arguments (from opcode)

Code:

Acquire (ECMX, 0xFFFF)
                Store (Zero, Local0)
                If (LEqual (Arg0, Zero))
                {
                    Store (EC00, Local0)
                }

                If (LEqual (Arg0, One))
                {
                    Store (EC01, Local0)
                }
...

If my EC is named ECDV, I will have to rename ECDV to EC, correct?
I saw that in my patched SSDT-12 there are references to ECDV. Would I need to rename them manually?

RehabMan said:
Your ioreg shows problems:
- UsbConnector value seem wrong. There should be 1:1 correspond between SSxx UsbConnector=3 and HSxx UsbConnector=3. I find 3x SSxx UsbConnector=3, but zero HSxx with UsbConnector=3.

I probably misunderstood your guide:

And we should change the UsbConnector values to match the type of port. The defaults are not always correct (USBInjectAll has no way to know what the correct value is).

Common port connector types are USB2 = 0, USB3 = 3, internal = 255.

Since when I plug in a USB3 device in one of the ports the appropriate SSxx is activated, but if to the same port I connect a USB2 device it is the corresponding HSxx that appears connected, I thought that I needed to differentiate the connector type for the two. However, now I know that we need to define the UsbConnector based on the physical port!

Thank you very much for answering all of my questions! I still wish the kext patches were documented somewhere, but at least I know what some of them do.

RehabMan said:
Great.
(that is a very common one...)
Hitting all the pinned threads and reading the FAQ is important.

True! One great problem I was facing though (and I guess many newcomers like myself) is that I did not even know what the right question to ask was. When I first installed High Sierra on this machine I was unfortunately following a guide that did neither mention nor reference your essential guides and in retrospective contained many mistakes. Obviously, there was no way to tell for me if what it suggested was correct or not, so when it said that disabling the Nvidia driver would equal disable the device itself I just believed it and would never have thought that my sleep/wake problem was related to an issue that I was "sure" I had fixed... While that is not meant as an excuse for my ignorance, it hopefully explains why I missed out on such an important topic.

Search

[SOLVED] wake causes freeze/panic in Dell 7577

B.A.C.H

Attachments

RehabMan

Moderator

B.A.C.H

RehabMan

Moderator

B.A.C.H

Attachments

RehabMan

Moderator

B.A.C.H

B.A.C.H

Attachments

RehabMan

Moderator

B.A.C.H

Forum

Guides

Downloads