Gigabyte B550 Vision D (Thunderbolt 3) + AMD Ryzen 7 3700X + AMD RX 5600 XT

[CaseySJ]

@mrdoodle

When creating new devices in SSDT, we must remove them from the DSDT if they already exist. This is done by renaming the originals, usually by replacing the first letter of the existing device name with the letter X. For example, GPP0 would become XPP0.

 

[mrdoodle]

Disabling the various ports and remapping PRW didn't seem to do anything helpful. It just moved the wake log back to "SWUS SWDS XHC2":

2023-08-25 11:55:18 -0600 Sleep                   Entering Sleep state due to 'Software Sleep pid=178':TCPKeepAlive=disabled Using AC (Charge:0%) 33 secs   
2023-08-25 11:55:51 -0600 DarkWake                DarkWake from Normal Sleep [CDN] : due to SWUS SWDS XHC2/ Using AC (Charge:0%) 46 secs   
2023-08-25 11:56:37 -0600 Wake                    DarkWake to FullWake from Normal Sleep [CDNVA] : due to UserActivity Assertion Using AC (Charge:0%)

However, I do want to report that there are at least 3 extra USB "devices" on my Radeon RX 6800XT and my suspicion is that something on this GPU is causing the immediate wake. @cccip, you may want to investigate further, because one of the USB devices is the RGB controller for the GPU. Yours may have something similar.

I couldn't figure out how to put the ACPI definition into an SSDT since their address looks like "*.pci1002,73a6@..." instead of something like "*.XHCI@..."

Okay, I think I'm going to have to stop investigating a solution here and live with no "sleep" on this machine. Instead at least I can put display and drives to sleep and live with ~70W idle for the time being:

sudo pmset -a displaysleep 1 disksleep 1 sleep 0 womp 1

Attaching my Radeon RX6800 XT USB port map that I put together in case anyone is interested. Disclaimer: I have no idea whether it works or not.

 

[cccip]

As I said earlier - if this is too much to spend a time on, don't bother. We'll happily live with no sleep on this board.
Benefits of having extra front USB-C port and dual 2.5G LAN ports still matters more over standard "Vision D" board

 

[Vorshim92]

Hello guys! How are you doing? A special shoutout to our good friend @CaseySJ, hope everything is going well.

I'm back to tinkering with the B550 Vision D! I had it replaced under warranty because I was having some issues with the Wi-Fi slot and two graphics cards, it was probably defective. I've installed a 5800x, an Nvidia 3080 in the first PCI slot for Windows (Gaming), an AMD 460 (flashed to 560) in the second PCI slot for OSX, and an ASUS XG-C100C gigabit LAN card in the third PCI slot! I've disabled the INTEL Wi-Fi, but it's still functional (I don't need it anymore).

Everything is working great, no problems. These days, I've been trying to get sleep/wake to work, but I'm still working on it, and it's not working for now. To disable the Nvidia card in PCI slot 1, I'm simply using "disable-gpu 01000000" in Device Prop... I suspect it might not be the best way to turn off the graphics card, maybe it would be better to use ACPI with SSDT and Method(_INI). I'm seeking clarification from you on this, it's your world xD @CaseySJ
any suggestions?

p.s. Additionally, while I was reading some logs, I noticed this ACPI error during the loading of a native SSDT of the motherboard. I'm attaching a photo and the extracted SSDT for your reference. it's
Is this something that can potentially cause issues in general?

 

[CaseySJ]

Hello guys! How are you doing? A special shoutout to our good friend @CaseySJ, hope everything is going well.

I'm back to tinkering with the B550 Vision D! I had it replaced under warranty because I was having some issues with the Wi-Fi slot and two graphics cards, it was probably defective. I've installed a 5800x, an Nvidia 3080 in the first PCI slot for Windows (Gaming), an AMD 460 (flashed to 560) in the second PCI slot for OSX, and an ASUS XG-C100C gigabit LAN card in the third PCI slot! I've disabled the INTEL Wi-Fi, but it's still functional (I don't need it anymore).

Everything is working great, no problems. These days, I've been trying to get sleep/wake to work, but I'm still working on it, and it's not working for now. To disable the Nvidia card in PCI slot 1, I'm simply using "disable-gpu 01000000" in Device Prop... I suspect it might not be the best way to turn off the graphics card, maybe it would be better to use ACPI with SSDT and Method(_INI). I'm seeking clarification from you on this, it's your world xD @CaseySJ
any suggestions?

p.s. Additionally, while I was reading some logs, I noticed this ACPI error during the loading of a native SSDT of the motherboard. I'm attaching a photo and the extracted SSDT for your reference. it's
Is this something that can potentially cause issues in general?

This ACPI patch should fix the error in GSWApp:

• Table Signature: SSDT
• OEMTableID: 47535741 7070
• Find: A00692 94600A0E
• Replace: A3A3A3 A3A3A3A3
• Comment: Fix TZ._STA function
• Count: 1
• Enabled: True

 

[mrdoodle]

@cccip Would you be able to try these two SSDTs (not at the same time!) to see if either fixes sleep on your build?

These SSDTs are only relevant for more recent BIOS versions for Vision D-P (ie. F15+), where they seem to have updated the ACPI config.

1. The first SSDT (SSDT-B550-VISION-DP-PT02-TO-XT02) reconfigures the PT02 ports (PT20-29) to use GPRW. The newer Gigabyte BIOSes seems to bypass GPRW and instead hard code the PRW return values of these devices. You could try other GPRW fixes (eg. SSDT-GPRW) along with this to see if that helps. With this one you need to also disable GPP0 separately as it is technically a separate issue.
2. The second SSDT (SSDT-DELETEPRW-PT21-22-23-GPP0) just deletes the PRW methods entirely from GPP0 and PT21, 22, 23 specifically.

Even with these patches, my machine is waking, but the reason moved from PT21, 22, 23, GPP0 etc to SWUS/SWDS which I think is the USB on the Radeon.

If your Radeon does not have USB, then I wonder if your wake would be fixed by either of these.

 

[Vorshim92]

This ACPI patch should fix the error in GSWApp:

• Table Signature: SSDT
• OEMTableID: 47535741 7070
• Find: A00692 94600A0E
• Replace: A3A3A3 A3A3A3A3
• Comment: Fix TZ._STA function
• Count: 1
• Enabled: True

View attachment 571356

Thank you @CaseySJ ! The error seems to have disappeared from the log thanks to this patch. Can I ask you about an issue I've been experiencing since I updated the BIOS to version 16? Even when I rolled back to version 15, the problem persisted. Essentially, it no longer detects 2 out of 4 SATA hard disks, 1 SSD, and 1 mechanical drive, and TestDisk is showing Bad Sector errors. On Windows, however, they load perfectly, and TestDisk doesn't detect any errors. The partitions on these 2 hard disks are NTFS, by the way. Please note that it takes a long time to get to the desktop now because I receive a lot of AHCI errors during boot. If I'm not mistaken, I believe it tries to perform an S.O.S. Recovery of the 2 hard disks during boot, which keeps it stuck for a while until I eventually reach the desktop. It recognizes the hard disks but doesn't load the partitions and asks me to initialize them. Obviously, since the hard disks work fine on Windows, I suspect there might be some issue in the EFI or somewhere else. I'm not sure if it was caused by the BIOS update or perhaps some sudden PC shutdown. Any ideas?

I attach the boot log and some screens from TestDisk from windows and osx and disk utility. This behavior is truly strange
is there any AHCI patch or kext I can try for this build?

 

[Vorshim92]

Thank you @CaseySJ ! The error seems to have disappeared from the log thanks to this patch. Can I ask you about an issue I've been experiencing since I updated the BIOS to version 16? Even when I rolled back to version 15, the problem persisted. Essentially, it no longer detects 2 out of 4 SATA hard disks, 1 SSD, and 1 mechanical drive, and TestDisk is showing Bad Sector errors. On Windows, however, they load perfectly, and TestDisk doesn't detect any errors. The partitions on these 2 hard disks are NTFS, by the way. Please note that it takes a long time to get to the desktop now because I receive a lot of AHCI errors during boot. If I'm not mistaken, I believe it tries to perform an S.O.S. Recovery of the 2 hard disks during boot, which keeps it stuck for a while until I eventually reach the desktop. It recognizes the hard disks but doesn't load the partitions and asks me to initialize them. Obviously, since the hard disks work fine on Windows, I suspect there might be some issue in the EFI or somewhere else. I'm not sure if it was caused by the BIOS update or perhaps some sudden PC shutdown. Any ideas?

I attach the boot log and some screens from TestDisk from windows and osx and disk utility. This behavior is truly strange
is there any AHCI patch or kext I can try for this build?

Hello guys! I just want you to know that I find the culprit! It was a bios settings in the SATA section
Here:

Chipset SATA Port Hot Plug
The BIOS update had automatically activated this feature. Now it's working again. I wanted to share this with you in case someone encounters the same issue in the future

 

[CaseySJ]

macOS Sonoma Installation Mini-Guide:

Asus Z690 ProArt Creator WiFi (Thunderbolt 4) + i7-12700K + AMD RX 6800 XT

The first bullet seems full of caveats: Bandwidth Boost provides up to 3 times the throughput for video-intensive usage, up to 120 Gbps. Not sure what this means. It may just be referring to the DisplayPort pins. Thunderbolt 3/4 is always symmetrical at 40 Gb/s each way. TB 5 will be 80 Gb/s...

www.tonymacx86.com

 

[cccip]

@cccip Would you be able to try these two SSDTs (not at the same time!) to see if either fixes sleep on your build?

These SSDTs are only relevant for more recent BIOS versions for Vision D-P (ie. F15+), where they seem to have updated the ACPI config.

1. The first SSDT (SSDT-B550-VISION-DP-PT02-TO-XT02) reconfigures the PT02 ports (PT20-29) to use GPRW. The newer Gigabyte BIOSes seems to bypass GPRW and instead hard code the PRW return values of these devices. You could try other GPRW fixes (eg. SSDT-GPRW) along with this to see if that helps. With this one you need to also disable GPP0 separately as it is technically a separate issue.
2. The second SSDT (SSDT-DELETEPRW-PT21-22-23-GPP0) just deletes the PRW methods entirely from GPP0 and PT21, 22, 23 specifically.

Even with these patches, my machine is waking, but the reason moved from PT21, 22, 23, GPP0 etc to SWUS/SWDS which I think is the USB on the Radeon.

If your Radeon does not have USB, then I wonder if your wake would be fixed by either of these.

I'll give it a try.
However - few things to mention....
I had to recreate a new USB port map kext, seeing GPP0 issues gone from logs while PT21,22,23 is still there and causing system wake. BUT whole system became unstable. So, I simply rolled back the EFI and dissmissed the idea to have system sleeping