Contribute
Register

Gigabyte Z690 Aero G + i5-12600K + AMD RX 6800 XT

NCMacGuy said:
There is interference between the Ethernet drivers on the Aero and the Apple Display. Between boots, one or the other may be active. Not a good situation.
Click to expand...
This suggests that you should turn OFF quirk DisableIoMapper, turn ON Vt-d in BIOS, add SSDT-DMAC.aml, drop the DMAR table and add the modified SSDT-DMAR.aml in order to fully enable AppleVTD.
 
dehjomz said:
So I wanted to understand your patch so I could know where to look in the Z590 ACPI table.
  • So from what I can tell, from post 147 of this thread (https://www.tonymacx86.com/threads/gigabyte-z690-aero-g-i5-12600k-amd-rx-6800-xt.317179/post-2291235) this patch targets the OEM GSWApp SSDT and replaces "43031419 41444247" with "43031419 58444247" or in other words it does "CADBG"->"CXDBG."
  • But there is no "CADBG" in the SSDT, instead it has rather it has a few occurrences of "ADBG." So why CADBG?
  • Second, the patch only replaces the first occurrence of this string. Why the first but not the others?
  • Third, what is effect of doing this? Just trying to understand why we're targeting this function for replacement.
Click to expand...
"43031419 41444247" is NOT "CADBG" but "C••• ADBG", where '•' stands for non-printable characters, and these are not changed. This adds some context to 'ADBG' to ensure that only the definition of this function is renamed. There is only one occurrence of the definition; other mentions of 'ADBG' are calls to this function, and should remain as such so that they will call the modified version in the new SSDT.
As to the last bullet point (what's ABDG doing, and what was missing for proper sleep?), I'll leave it for @CaseySJ to answer.
 
etorix said:
"43031419 41444247" is NOT "CADBG" but "C••• ADBG", where '•' stands for non-printable characters, and these are not changed. This adds some context to 'ADBG' to ensure that only the definition of this function is renamed. There is only one occurrence of the definition; other mentions of 'ADBG' are calls to this function, and should remain as such so that they will call the modified version in the new SSDT.
As to the last bullet point (what's ABDG doing, and what was missing for proper sleep?), I'll leave it for @CaseySJ to answer.
Click to expand...
Good! I need a better translator from hex to string!! The translator truncated the binary characters.
 
You only need Hex Fiend.app and MaciASL.app. Hex translator? I use Hackintool.app.
 
Last edited:
StefanAM said:
@Elias64Fr, :( unfortunately, I have same symptoms. If I boot with my TB dock, it stops before login. If hot plug, it crash in 15 sec. What can I try more?
Click to expand...
Hey @Elias64Fr! Like I told you, the patched SSDT-SocGpePatched.aml doesn't help me. Anything else to try?
 
dehjomz said:
Hi @CaseySJ, question about your ACPI patch, specifically the ADBG -> XDBG patch. Want to understand better the reasoning behind it.

Also I want to try to adapt it to Z590 to it so I could upgrade from my beta bios. I was using an older beta bios because it sleeps fine with macOS, but the newer public BIOSes have the issue of restart from 2nd wake from sleep in macOS, same as we encountered with z690. I wanted to move to the newer bioses because they use the latest Rocket Lake microcode (and have a 3-4 degree C cooler temp at idle).

So I wanted to understand your patch so I could know where to look in the Z590 ACPI table.
  • So from what I can tell, from post 147 of this thread (https://www.tonymacx86.com/threads/gigabyte-z690-aero-g-i5-12600k-amd-rx-6800-xt.317179/post-2291235) this patch targets the OEM GSWApp SSDT and replaces "43031419 41444247" with "43031419 58444247" or in other words it does "CADBG"->"CXDBG."
  • But there is no "CADBG" in the SSDT, instead it has rather it has a few occurrences of "ADBG." So why CADBG?
  • Second, the patch only replaces the first occurrence of this string. Why the first but not the others?
  • Third, what is effect of doing this? Just trying to understand why we're targeting this function for replacement.
Thanks!

Edit: tried ADBG->XDBG on Z690. Doesn't do anything, doesn't work. Your original patch (CADBG->CXDBG) works.
Click to expand...
@dehjomz

Determining how to fix/patch this particular ACPI error was rather straightforward. Nothing as painstaking as figuring out a kernel patch with a disassembler. The ACPI patch was determined as follows:
  • macOS boot log contained an AE_ALREADY_EXISTS error for ADBG in the GSWApp table. This prevented the entire GSWApp table from loading, which is a particularly bad thing because there are more than 8000 lines of ACPI code in there.
  • So if ADBG already exists, then where is it first defined? Turns out that it's already defined in DSDT. So we compare the two definitions, one from DSDT and the other from GSWApp:
JavaScript: 
// from DSDT
        Scope (\)
        {
            Method (ADBG, 1, Serialized)
            {
                If (CondRefOf (ODBG))
                {
                    ODBG (Arg0)
                }

                Debug = Arg0
                If (CondRefOf (MDBG))
                {
                    Return (MDBG (Arg0))
                }

                Return (Zero)
            }
        }
JavaScript: 
// from GSWapp
        Method (ADBG, 1, Serialized)
        {
            If (CondRefOf (\MDBG))
            {
                Return (\MDBG (Arg0))
            }

            Return (Zero)
        }
Both methods are defined at root scope, hence the conflict. We also see that both versions do the same thing, which is to call MDBG with the first argument passed into the method.

Based on this there are two possible solutions:
  • Solution 1:
    • Modify Method (ADBG, 1, Serialized) to something like Method (XDBG, 1, Serialized), but within GSWApp only.
    • All invocations of ADBG that are present in GWSApp will now be routed to the one and only Method (ADBG, ...) in DSDT.
    • Figuring out the actual Find and Replace values requires opening the original (not re-compiled) .aml file (SSDT-0-GSWApp) in Hex Fiend and looking for the compiled ACPI byte code corresponding to "Method (ADBG...", then changing that section of byte code to "Method (XDBG...".
    • Because "Method (ADBG..." appears at the end of the SSDT, we simply scroll Hex Fiend to the end as well, and we find this:
      Screen Shot 2021-11-24 at 4.05.14 AM.png
    • In the screenshot above, the first 4 bytes are selected in order to target this particular instance and none other. Now we replace "A" with "X" by changing 0x41 to 0x58.
  • Solution 2:
    • Replace all occurrences of ADBG with XDBG within GSWApp only.
    • This is simpler to specify in config.plist. And I may switch to this version in the future.
 
Last edited:
I tried this out on my Z590 Aorus Elite AX and I can confirm it fixes sleep. I used the rename method from post #240
 
Last edited:
StefanAM said:
You only need Hex Fiend.app and MaciASL.app. Hex translator? I use Hackintool.app.
Click to expand...
Just a quick tool to convert from hex to ASCII. I’ve been using some website but I will use hex fiend in the future.
 
dehjomz said:
Hi @CaseySJ here is my boot log and ACPI table from the z590 Vision D. I'm running the BIOS that restarts upon the second wake from sleep. I applied the patches from Z690 but they don't fix sleep on this BIOS.

Edit: Never mind. Solution is

Patch: Table GSWApp
  • Table Signature: SSDT
  • OemTableID: 47535741 7070
  • Find: 43031419 41444247
  • Replace: 43031419 58444247
  • Comment: Change CADBG to CXDBG
  • Count = 1
  • Limit = 0
  • Skip = 0
  • Enabled = True

With this, sleep/wake works on multiple cycles on z590 Vision D! Hopefully this can help others as well.

The older beta BIOS that I was using didn't have the ADBG function defined at all... so it slept fine. But for some reason, the newer Z590 Vision D bioses (like F5, F6, and this beta one I'm using that enables thunderbolt 'kernel DMA protection' in Windows) define this function for some reason and it interferes with sleep.

The onboard Maple ridge controller resumes from sleep as well, but key is to set 'Wake from Thunderbolt Devices' on. The first sleep/wake cycle after doing so, may result in it hanging, and so maple ridge may not come back. But the 2nd sleep cycle and onward it will come back from sleep...
Click to expand...
The boot log you posted contains 3 table load failures (edited below for brevity):
Code: 
//
// ADBG already exists --> SSDT GSWApp
//
kernel: (AppleACPIPlatform) ACPI Error:
kernel: (AppleACPIPlatform) [ADBG]
kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_ALREADY_EXISTS
kernel: (AppleACPIPlatform)  (20160930/dswload-462)
kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
kernel: (AppleACPIPlatform) During name lookup/catalog
kernel: (AppleACPIPlatform)  (20160930/psobject-310)
kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
kernel: (AppleACPIPlatform) (SSDT:  GSWApp) while loading table
...
//
// Device _SB_.PC00.XHCI.RHUB.HS01 not found --> SSDT xh_rksu4
//
kernel: (AppleACPIPlatform) ACPI Error:
kernel: (AppleACPIPlatform) [\_SB_.PC00.XHCI.RHUB.HS01]
kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
kernel: (AppleACPIPlatform)  (20160930/dswload-292)
kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
kernel: (AppleACPIPlatform) During name lookup/catalog
kernel: (AppleACPIPlatform)  (20160930/psobject-310)
kernel: (AppleACPIPlatform) ACPI Exception: AE_NOT_FOUND,
kernel: (AppleACPIPlatform) (SSDT:xh_rksu4) while loading table
...
//
// Method _STA already exists (multiple definition) --> SSDT SsdtEC
//
kernel: (AppleACPIPlatform)  (20160930/tbxfload-319)
kernel: (AppleACPIPlatform) ACPI Error:
kernel: (AppleACPIPlatform) [_STA]
kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_ALREADY_EXISTS
kernel: (AppleACPIPlatform)  (20160930/dswload-462)
kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
kernel: (AppleACPIPlatform) During name lookup/catalog
kernel: (AppleACPIPlatform)  (20160930/psobject-310)
kernel: (AppleACPIPlatform) ACPI Exception: AE_ALREADY_EXISTS,
kernel: (AppleACPIPlatform) (SSDT:  SsdtEC) while loading table
...
kernel: (AppleACPIPlatform) 3 table load failures, 19 successful
kernel: (AppleACPIPlatform) 3 table load failures, 19 successful
Homework assignment? :)
 
CaseySJ said:
@dehjomz

Determining how to fix/patch this particular ACPI error was rather straightforward. Nothing as painstaking as figuring out a kernel patch with a disassembler. The ACPI patch was determined as follows:
  • macOS boot log contained an AE_ALREADY_EXISTS error for ADBG in the GSWApp table. This prevented the entire GSWApp table from loading, which is a particularly bad thing because there are more than 8000 lines of ACPI code in there.
  • So if ADBG already exists, then where is it first defined? Turns out that it's already defined in DSDT. So we compare the two definitions, one from DSDT and the other from GSWApp:
JavaScript: 
// from DSDT
        Scope (\)
        {
            Method (ADBG, 1, Serialized)
            {
                If (CondRefOf (ODBG))
                {
                    ODBG (Arg0)
                }

                Debug = Arg0
                If (CondRefOf (MDBG))
                {
                    Return (MDBG (Arg0))
                }

                Return (Zero)
            }
        }
JavaScript: 
// from GSWapp
        Method (ADBG, 1, Serialized)
        {
            If (CondRefOf (\MDBG))
            {
                Return (\MDBG (Arg0))
            }

            Return (Zero)
        }
Both methods are defined at root scope, hence the conflict. We also see that both versions do the same thing, which is to call MDBG with the first argument passed into the method.

Based on this there are two possible solutions:
  • Solution 1:
    • Modify Method (ADBG, 1, Serialized) to something like Method (XDBG, 1, Serialized), but within GSWApp only.
    • All invocations of ADBG that are present in GWSApp will now be routed to the one and only Method (ADBG, ...) in DSDT.
    • Figuring out the actual Find and Replace values requires opening the original (not re-compiled) .aml file (SSDT-0-GSWApp) in Hex Fiend and looking for the compiled ACPI byte code corresponding to "Method (ADBG...", then changing that section of byte code to "Method (XDBG...".
    • Because "Method (ADBG..." appears at the end of the SSDT, we simply scroll Hex Fiend to the end as well, and we find this:
      View attachment 535406
    • In the screenshot above, the first 4 bytes are selected in order to target this particular instance and none other. Now we replace "A" with "X" by changing 0x41 to 0x58.
  • Solution 2:
    • Replace all occurrences of ADBG with XDBG within GSWApp only.
    • This is simpler to specify in config.plist. And I may switch to this version in the future.
Click to expand...
So if I understand what you’re saying, there’s a naming conflict At the function definition level? Which also prevents the ACPI table from loading? So gigabyte or intel screwed up in how they defined the function definitions in GSWApp? Should they have named it some thing else?

And by renaming adbg->xdbg as we do in GSWApp, that resolves the function definition conflict, and not only allows GSWApp ssdt to load, but also, the calls to adbg (in GSWApp) to be routed to the proper function in the DSDT?

Secondly, I noticed before the patch was applied, when macOS resumed from sleep on the z590 vision d, post code was 00. But with the patch applied, resume from sleep has the normal post code 03. So I guess the failure of the GSWApp loading was why sleep was broken as clearly different acpi code is run during resume from s3 sleep, as compared to the case without the patch.
 
Last edited:
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top