Dual 6900 XT Issues

[Edhawk]

I saw your post over at IM regarding the SSDT-CPU-WRAP table. I didn't fully understand what it did for a HEDT system, thanks for explaining

 

[etorix]

You're most welcome.
Credits for all the detective work and technical solution goes to @metacollin. I'm merely a moderately competent imitator. (And not a programmer or someone otherwise trained in computer science.)

You do not dive into this ACPI stuff until you're bitten by it. So far, ACPI 6.3 had only bitten a handful of C621 users—but it now trickles down to C422 users. I suppose that regular users are saved by the "ship and forget" and "let's keep designing for old software" attitude of manufacturers when it comes to mainstream consumer hardware. As new hardware will eventually not be suitable for OS X at all, the larger hackintosh community may well be spared from this issue.
But, in case someone ever posts for help because he can longer boot his perfectly working OS X installation after a BIOS update (boot halts shortly after the picker no matter what he tries, etc.), it's good that is some awareness about "ACPI 6.3 processor devices" in the community.

 

[ramazarusx]

First I'd like to give my sincere thank you to all of you who's taking their time and helping me with this issue, you can't imagine how much I appreciate this.

Sorry guys I can't seem to figure out how this multi-quote thing works so I'll do the old way.

Thanks for sharing!

Thank you for helping me.

So SSDT-SLEEP is (was?) for debug purposes. There's nothing to fix the system bus, no USB map and you're still using the port limit quirk—but you've solved the sleep issue otherwise.
Any reason why you've introduced SSDT-IMEI from the previous C612 generation?

Was and wasn't, it didn't do what it did with x299 system or unless somehow I screwed up.

I'm not familiar yet with these path fixing SSDTs, but the GFX1 SSDT lacks the _DSM method of GFX0.
If you introduce and load this modified SSDT-GFX1, does it make any change to the behaviour of the second GPU in slot 3 or to the way it's displayed in IORegistryExplorer?

Sorry I'm not sure what do you mean?


@Edhawk and @etorix Attaching DSDT.aml dump from OC

In my (admittedly limited) experience with C422 and C621 boards, while Dortania's documentation is generally very thorough and works perfectly with consumer boards, the HEDT guide follows the consumer guide too closely and is not by itself sufficient to successfully boot a server/workstation-class board. For instance, the Kernel section does NOT mention unlocking MSR 0x1AA (AppleXcpmExtraMsrs), which is an additional requirement to boot on this class of hardware, similar and alongside to unlocking MSR 0xE2 (AppleXcpmCfgLock).

You're absolutely right without patching 0X1AA the system just hangs on C621 board well at least on ASUS it does, and seem that the lates UEFI patch doesn't completely patch the bios or screws something up because whilst the patched bios WILL let you boot it'll cause an instant kernel panic o the wake from sleep, but if done from OC sleep and wake are perfect.

That's actually perfectly fine!
Server/HEDT boards now tend to comply with ACPI 6.3 specification and generically define their processors as "devices" while OS X expects to find ACPI 6.2 "processor" objects. With such an ACPI 6.3 DSDT, the OS X boot process stalls just after loading ACPI tables because OS X cannot find a processor to run onto—which is quite a bummer.
@metacollin devised a solution by wrapping the CPxx devices and their methods in PRxx processor objects, which is what the SSDT-CPU-WRAP does. Any further SSDT which refers to processors, such as SSDT-PLUG, should then load after SSDT-CPU-WRAP and attach to the wrapping PRxx objects and not to the actual CPxx devices.

It took me a while to figure out what the hell was the issue until I saw your post about PR/CP screwups. I don't remember if I modified your CPU-WRAP file or used as it is but it was a MUST to boot.

I have seen only few ACPI 6.3 DSDTs so far, and I own only one of these boards—which is not enough to get to the bottom of this CPU wrapping wizardry. After making my own SSDT, I found I could actually boot with @metacollin 's SDDT cut down to one socket, although my Gigabyte board and his Supermicro board do not define the same set of methods and functions for their processors (and not all of these are defined in the DSDT). So it doesn't appear necessary to wrap up everything.
Someone has suggested that it is sufficient to wrap just the CPUs themselves (like what Dortania is now doing for HyperV), but I could not succeed and confirm this. Examining ACPI tables from yet another manufacturer could be of interest.

Wish I had enough knowledge to answer this. The problem with our type of board is that the boot time is long and A/B testing takes ages to do.

Even with both GFX0 and GFX1 working in the system still the second GPU won't be recognized.

I'm attaching 2 IOReg files, one with 2 GPUs only 1 display connected on DPI(if more then 2 connected they don't work, have to unplug, plug back in and wait for a bout minute or two for it to get back) and PCIE3 disabled 1 GPU with 3 displays connected(2 DPI 1 HDMI).

Also attaching raw DSDT.aml dump from OC.

Again thank you fellas for everything.

 

[Edhawk]

I'll have a look at this tomorrow (Tuesday) and get back to you with any thoughts or recommendations.

 

[ramazarusx]

I'll have a look at this tomorrow (Tuesday) and get back to you with any thoughts or recommendations.

Thank you very much.

 

[Edhawk]

Single GPU
The ACPI path (address) for the single GPU with three active displays is

IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0

This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) or (SB.PC02.BRA2.D035.BRG0) so the path(s) used in the SSDT you tried were wrong.

The ATY,RadeonFramebuffer Ports 0, 1 & 2 were shown as having a display connected.

• Connectors 0 & 1 via DisplayPort (0x400)
• Connector 2 via HDMI (0x800)
• Connector 3 is set as a Dummy connector (0x0) no display.

I have assumed that this card is mounted in the uppermost PCIe x16 slot, 'Slot-1' and that it covers 'Slot-2' from being used.


Dual GPUs
In comparison the IOReg ACPI Paths for the dual GPU setup were as follows:

IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 - GPU 1
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) & (SB.PC02.BRA2.D035.BRG0), matching the paths when only one GPU was installed.

IOACPIPlane:/_SB/PC03@0/BR3A@0/D037@ffff - GPU 2
Translates as (SB.PC02.BRA3.D037) and stops, there is no GFX1 associated with this GPU. It shows no connectors being available, unsurprisingly. So it probably doesn't work and is probably just sitting there wasting electricity.

Which 'Slot' is this card mounted within, 'Slot-3', i.e. third from top?

You do not appear to have WhateverGreen.kext or AppleALC.kext installed in your system, can I ask why not? Under the Resources section of both IOReg's only Lilu.kext is showing as being present.

Provide copy of EFI
Can you post a copy of your EFI folder, but remove the Serial, MLB, ROM etc. from your config.plist so we can see what you are using to boot your system.

I have assumed you don't have any third-party kexts installed in your /Library/Extensions or /System/Library/Extensions folder.


USB ports
(Off Topic) Your USB configuration is a bit off to my mind. You have ports HS01-HS08 inclusive and SS01-SS06 inclusive active in your system. They all have the same connector Type (0xff), which I believe means all the ports are set as USB2. This is very wrong as the SSxx ports should be set as USB3 and some of the HSxx ports should also be set as USB3, others as 'Internal' (bluetooth connection). You have a few USB3.1/2 Type-C ports, which do not seem to be active or are not included in the setup you are using.

Only the ports that are physically USB2 should be set with the USB2 connector type. Any virtual USB2 ports served from a Physical USB3 port should be set with the connector type USB3. Your X299 Workstation board doesn't have any USB2 ports on the rear I/O plate, as can be seen in the screenshot below of the rear I/O plate:



The motherboard appears to have the following internal USB Headers:

• 1 x USB2 header, providing 2 ports, which should be set with the connector type 'Internal' not USB2.
  • HS07 serving your Bluetooth module should be set as 'Internal' (255) if this is the only port connected to the internal USB2 header.
• 1 x USB3 header, providing 4 ports, which should be set with the 'USB3' connector type, probably connected to your front case USB3 ports, and
• 1 x USB3.1/2 Type-C header, again probably connected to a front case port if used. These and the one on the rear should be set with the 'Type-C' or 'Type-C+sw' connector types, not USB2 or USB3.

You would be advised to read and follow this guide for USB configuration by UtterDisbelief - https://www.tonymacx86.com/threads/the-new-beginners-guide-to-usb-port-configuration.286553/

 

[etorix]

@Edhawk Thanks for your insights.
The config.plist provided above shows WhateverGreen… but disabled. Perhaps the effect of too many "Snapshot" (not "Clean Snapshot") in ProperTree?
Anyway, I suppose the next thing to try would be with WhateverGreen enabled, loaded, and no GFX SSDT.

AppleALC is enabled in the config.plist though. So its absence in IOReg is a mystery…

The system for which help is required is the work-in-progress Asus Pro C621-64L Sage/10G in @ramazarusx signature, not the (presumably fully working) X299 board currently under his profile.
4 back USB 3.2 Gen 1, 1 USB 3 header, 1 USB 2 header + 2 USB 3.2 Gen 2 (ASMedia controller)
This should be within the 15 port limits but doing a full USB map and removing the port limit quirk can only improve stability.

Sorry guys I can't seem to figure out how this multi-quote thing works so I'll do the old way.

Click on "+ Quote", then click "Reply".
Put the pointer in the quoted message where you want to cut and hit "return". Repeat as needed.

Was and wasn't, it didn't do what it did with x299 system or unless somehow I screwed up.

Or maybe SSDT-SLEEP doesn't work on C621 as it does on X299. (Is there documentation on it somewhere?)
Has it brought any visible improvement? If not, I'd suggest to remove it.
Same question, and same suggestion for SSDT-IMEI. Or had you put it in response to a kernel message about IMEI?

You're absolutely right without patching 0X1AA the system just hangs on C621 board well at least on ASUS it does, and seem that the lates UEFI patch doesn't completely patch the bios or screws something up because whilst the patched bios WILL let you boot it'll cause an instant kernel panic o the wake from sleep, but if done from OC sleep and wake are perfect.

I realised that anyone could download the firmware and tried patching 1102 and 6702. The process appeared to work for both, with 28 and 24 bytes replaced. But of course it takes the actual board to check there is no side effect. If you think that reverting to the original firmware has solved the sleep issue, I'd recommend removing all other attempts at fixing sleep.

Also attaching raw DSDT.aml dump from OC.

My wrapping SSDT does what it should for all CPU methods from the DSDT. Can't tell about further CPU methods which could be defined in SSDT*.aml or OEM*.aml files—that's why I look at the full SysReport folder for wrapping. I wondered whether Asus defined some method for CPU power states which is not used by Gigabyte, and thus is not wrapped by my SSDT, and whether this could explain the sleep issue. But if the unpatched firmware fixes your sleep issue, all is well.

I used your DSDT to make a further SSDT to fix the system bus for OS X. This is not necessary to boot but recommended by Dortania post-install.

 

[ramazarusx]

Single GPU
The ACPI path (address) for the single GPU with three active displays is

IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0

This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) or (SB.PC02.BRA2.D035.BRG0) so the path(s) used in the SSDT you tried were wrong.

I think you were looking at IOReg with the SSDT active in the system, this is the IOReg without SSDT for GFX0

Attaching the Clean IOReg.

Dual GPUs
In comparison the IOReg ACPI Paths for the dual GPU setup were as follows:

IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 - GPU 1
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) & (SB.PC02.BRA2.D035.BRG0), matching the paths when only one GPU was installed.

IOACPIPlane:/_SB/PC03@0/BR3A@0/D037@ffff - GPU 2
Translates as (SB.PC02.BRA3.D037) and stops, there is no GFX1 associated with this GPU. It shows no connectors being available, unsurprisingly. So it probably doesn't work and is probably just sitting there wasting electricity.

Thats my problem, I even installed the windows to test it the second GPU works perfectly fine under windows.

Which 'Slot' is this card mounted within, 'Slot-3', i.e. third from top?

"Technically" yes

You do not appear to have WhateverGreen.kext or AppleALC.kext installed in your system, can I ask why not? Under the Resources section of both IOReg's only Lilu.kext is showing as being present.

Provide copy of EFI
Can you post a copy of your EFI folder, but remove the Serial, MLB, ROM etc. from your config.plist so we can see what you are using to boot your system.

I have assumed you don't have any third-party kexts installed in your /Library/Extensions or /System/Library/Extensions folder.

Attached.

USB ports
(Off Topic) Your USB configuration is a bit off to my mind. You have ports HS01-HS08 inclusive and SS01-SS06 inclusive active in your system. They all have the same connector Type (0xff), which I believe means all the ports are set as USB2. This is very wrong as the SSxx ports should be set as USB3 and some of the HSxx ports should also be set as USB3, others as 'Internal' (bluetooth connection). You have a few USB3.1/2 Type-C ports, which do not seem to be active or are not included in the setup you are using.

To be quite honest I just didn't have a chance to look into USB, I was waiting to get both GPUs working then the TB3/4 then get the all USB ports setup.


------------

@Edhawk Thanks for your insights.
The config.plist provided above shows WhateverGreen… but disabled. Perhaps the effect of too many "Snapshot" (not "Clean Snapshot") in ProperTree?
Anyway, I suppose the next thing to try would be with WhateverGreen enabled, loaded, and no GFX SSDT.

I actually tried that with 0 results, I get black screen with/without Pikera argument.

The system for which help is required is the work-in-progress Asus Pro C621-64L Sage/10G in @ramazarusx signature, not the (presumably fully working) X299 board currently under his profile.
4 back USB 3.2 Gen 1, 1 USB 3 header, 1 USB 2 header + 2 USB 3.2 Gen 2 (ASMedia controller)
This should be within the 15 port limits but doing a full USB map and removing the port limit quirk can only improve stability.

Yup x299 works perfectly, I just left the USB at the end since its the easiest thing to fix.

Click on "+ Quote", then click "Reply".
Put the pointer in the quoted message where you want to cut and hit "return". Repeat as needed.

Thank you!

Or maybe SSDT-SLEEP doesn't work on C621 as it does on X299. (Is there documentation on it somewhere?)
Has it brought any visible improvement? If not, I'd suggest to remove it.
Same question, and same suggestion for SSDT-IMEI. Or had you put it in response to a kernel message about IMEI?

I removed both of them, IMEI I think was there because I guess it was late and I put it there without realizing that I didn't need it. Removed Sleep lets see what happens.

I realised that anyone could download the firmware and tried patching 1102 and 6702. The process appeared to work for both, with 28 and 24 bytes replaced. But of course it takes the actual board to check there is no side effect. If you think that reverting to the original firmware has solved the sleep issue, I'd recommend removing all other attempts at fixing sleep.

I'm 6702 with both patched by OC works perfectly fine and got full sleep, its the BIOS patching that was causing the panic.

My wrapping SSDT does what it should for all CPU methods from the DSDT. Can't tell about further CPU methods which could be defined in SSDT*.aml or OEM*.aml files—that's why I look at the full SysReport folder for wrapping. I wondered whether Asus defined some method for CPU power states which is not used by Gigabyte, and thus is not wrapped by my SSDT, and whether this could explain the sleep issue. But if the unpatched firmware fixes your sleep issue, all is well.

Attaching the SysReport.

I used your DSDT to make a further SSDT to fix the system bus for OS X. This is not necessary to boot but recommended by Dortania post-install.

Already installed, Thank you very much.

Thank you all for all the help, I really appreciate that!

 

[etorix]

Thanks for the uploads!

Then, if WhateverGreen, enabled, did not suffice to activate your two GPUs we need to look into the contents of the SSDTs. I think that @Edhawk made typing errors and the ACPI paths are actually fine.

Dual GPUs
In comparison the IOReg ACPI Paths for the dual GPU setup were as follows:

IOACPIPlane:/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 - GPU 1
This translates to (SB.PC02.BRA2.D035.BRG0.GFX0) & (SB.PC02.BRA2.D035.BRG0), matching the paths when only one GPU was installed.

IOACPIPlane:/_SB/PC03@0/BR3A@0/D037@ffff - GPU 2
Translates as (SB.PC02.BRA3.D037) and stops, there is no GFX1 associated with this GPU. It shows no connectors being available, unsurprisingly. So it probably doesn't work and is probably just sitting there wasting electricity.

/_SB/PC02@0/BR2A@0/D035@ffff/BRG0@0/GFX0@0 should translate to
_SB.PC02.BR2A.D035.BRG0.GF0, not to BRA2. Same for BR3A / BRA3.

Your SSDT-GFX1 just creates BRG0 and GFX1 objects.

DefinitionBlock ("", "SSDT", 2, "ACDT", "BRG0", 0x00000000)
{
    External (_SB_.PC03.BR3A.D037, DeviceObj)

    Scope (\_SB.PC03.BR3A.D037)
    {
        Device (BRG0)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Device (GFX1)
            {
                Name (_ADR, Zero)  // _ADR: Address
            }
        }
    }
}

While SSDT-GFX0 further provides GFX0 with a _DSM method… which creates a package but does nothing useful with it.

DefinitionBlock ("", "SSDT", 2, "ACDT", "BRG0", 0x00000000)
{
    External (_SB_.PC02.BR2A.D035, DeviceObj)

    Scope (\_SB.PC02.BR2A.D035)
    {
        Device (BRG0)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Device (GFX0)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b") /* Unknown UUID */))
                    {
                        Local0 = Package (0x06)
                            {
                                "built-in",
                                Buffer (One)
                                {
                                     0x00                                             // .
                                },

                                "AAPL,slot-name",
                                Buffer (0x07)
                                {
                                    "Slot-1"
                                },

                                "model",
                                Buffer (0x16)
                                {
                                    "AMD Radeon RX 5700 XT"
                                }
                            }
                    }

                    Return (Zero)
                }
            }
        }
    }
}

Which one is correct? And shouldn't _DSM() return its package rather than 0?

 

[etorix]

Looking at all ACPI tables, this Asus board defines exactly the same CPU methods as my Gigabyte board, spread exactly in the same manner between the DSDT, one SSDT and four OEM1-OEM4 files which are conditionally loaded from methods in the SSDT. I saw the same situation in the tables of the X11SRA-F, BIOS v.2.4—which is not even a C621 board.
I thought wrapping SSDTs would be board-specific, or at least manufacturer-specific, but so far my SSDT fits boards from three manufacturers. @metacollin 's X11DAi-N is so far a lone outsider.

Back to the dual display issue.
I suppose that "Clean IOReg" was produced by booting from the accompanying EFI folder; so WhateverGreen was still disabled and no SSDT-GFX was loaded. Correct?
The board from PC02 (top slot , "slot-1") looks quite functional, with three displays on 2*DP and 1*HDMI and HDMI audio; I have a doubt about the USB-C ports (Framebuffer@3 with connector-type 0 instead of 0x400 for DP).
There was nothing from PC03 ("slot-3"): Was the secondary GPU removed or was it present and not detected at all?

I took an educated guess that the USB2 header is HS07/08 and edited your EFI folder to load WhateverGreen.
How does it work with one or two GPUs?
Update I might have missed boot-arg 'agdpmod=pikera' if it's necessary for RX6000.

Update 2 I had missed that you already tried WEG with and without this argument. So this EFI is probably pointless.