Ongoing Progress - Big Sur on Gigabyte B550 Vision D - AMD Ryzen 7 3700X - Thunderbolt 3

[CaseySJ]

Could you try sleep/wake with Thunderbolt controller off from BIOS?

Disabling the Thunderbolt controller in BIOS did not help, unfortunately.

I compared the detailed system log immediate after wake-from-sleep between:

• X570 Taichi with AMD Ryzen 9 3900X
• B550 Vision D with AMD Ryzen 7 3700X
• Both are running Big Sur Public Beta 3

The X570 system sleeps and wakes properly, so it gives a baseline to compare. First, let's compare the GOOD log and the BAD log side by side...

In this screenshot we see the log messages that start as soon as the system WAKES from sleep. The GOOD log is on the LEFT. The BAD log on the right. In the yellow box we see the transition from SLEEP_STATE to ON_STATE. So this means that the B550 Vision D is indeed waking up.

MacOS starts the wake process. But immediately we see a possible problem with SMCAMDProcessor.kext on the right. There is no mention of this in the X570 boot log.

Suspicion #1: Does SMCAMDProcessor.kext need to be modified to fully support B550? UPDATE: This board appears to have IT8795E chips, which is supported by VirtualSMC. Additionally, running the system without SMCAMDProcessor.kext still allows the system to sleep, but not to wake.

In the next screenshot we see additional issues on the B550 Vision D that do not appear in the wake log from X570:

• There's a flood of mDNSResponder notifications. It seems that WiFi could not be re-enabled.
• All of the USB 2.0 ports (PO9, PO10, PO11) have a "timeout". There are no such logs for USB 3.0 ports.
• In the X570 wake log, there is no mention of "AppleUSB20XHCI", which means no issue at all with USB 2 ports.

Suspicion #2a: WiFi is not being enabled. USB 2.0 ports are also timing out. ACPI issue with S3 (sleep) to S0 (power on) transition on these devices?

Moving along, we see more clear evidence of WiFi reactivation failure. On the left (X570 Taichi) we see that WiFi has resumed properly, but none of those logs appear in the B550 wake log.

Suspicion #2b: WiFi does not resume on the B550 Vision D. Again, there could be one single root cause that is having multiple downstream consequences.

Finally -- and this is particularly damning -- the B550 wake log has over 10,000 lines of zone_map_exhausted. But the X570 wake log has ZERO such logs!

Suspicion #3: These may also be a domino effect from some initial problem.

 

[MACAK]

Man @CaseySJ, that is really great! Must be having some AMD fun!

 

[xtreem.p]

so... so far only wake is the problem... i can live with that!
Do we know if there is an active driver development for the built in Wifi and Bluetooth?

 

[Inqnuam]

Disabling the Thunderbolt controller in BIOS did not help, unfortunately.

I compared the detailed system log immediate after wake-from-sleep between:

• X570 Taichi with AMD Ryzen 9 3900X
• B550 Vision D with AMD Ryzen 7 3700X
• Both are running Big Sur Public Beta 3

...

very interesting.
the problem is still there with the original Intel WiFi card?

Can you make a log file of wake process with Ubuntu?

 

[CaseySJ]

so... so far only wake is the problem... i can live with that!
Do we know if there is an active driver development for the built in Wifi and Bluetooth?

Both AppleIntelBluetooth and itlwm (for WiFi) are in development, but a bit rough at this time. Namely:

• Bluetooth: Handoff/Continuity features don't work, but normal Bluetooth devices will connect.
• WiFi: Transfer speeds on AX200/AX201 WiFi 6 modules are extremely slow -- around 20 Mbps.

 

[CaseySJ]

very interesting.
the problem is still there with the original Intel WiFi card?

Yes, it occurs with original WiFi card as well.

Can you make a log file of wake process with Ubuntu?

Will put this on the to-do list...

 

[Ploddles]

On the TRx40, some people have overcome the sleep problem by enabling DevirtualiseMmio and adding a MMIOWhitelist (enabling 14 or 15 of them) in the Booter section of OC. Maybe something for you to have a look at in due course. The 2 you have listed, but not enabled, are incorrect, for our boards at least.

Where you say:-

NVMe SSDs:

• Although the board has two M.2 slots for NVMe and SATA SSDs, macOS will treat those devices as external instead of internal. This happens on most (or all?) AMD motherboards.

On my motherboard, the M2 NVMes are treated as internal, and the correct icons are used. However, the disks connected to the normal SATA ports are treated as external. I'll fix this is due course. Odd that it's different for my MB but I believe other TRX40 boards behave the same as yours.

You also say that you have renamed the USB controllers and mapped the USB ports with a kexts. Just trying to understand more on this but as each controller has less than 15 USB ports on it, is this necessary? (I understand why it is the case on Intel boards with the single controller and 20+ logical USB ports). If it is necessary, or optimal, then I'll have to try and work put how to do it for my MB.

 

[CaseySJ]

On the TRx40, some people have overcome the sleep problem by enabling DevirtualiseMmio and adding a MMIOWhitelist (enabling 14 or 15 of them) in the Booter section of OC. Maybe something for you to have a look at in due course. The 2 you have listed, but not enabled, are incorrect, for our boards at least.

I ran some experiments with this:

• Installed debug version of OpenCore 0.6.1, enabled logging to file, and obtained list of MMIO addresses from the log file in EFI partition.
• Converted the addresses to decimal and entered them in the MMIOWhiteList table with all entries enabled (which means they will remain virtualized).
• Enabled the DevirtualizeMMIO checkbox.
• Then uncheckedone of the MMIO White List entries starting with the one with most pages (0x2000 pages).
  • System booted fine, but no wake from sleep.
• Then unchecked another one (while keeping the first one also unchecked). This time 0x1000 pages.
  • System booted fine, but no wake from sleep.
• Then unchecked one with 0x100 pages.
  • System did not finish booting.
  • So checked it back on.
• Then unchecked one with 0x200 pages.
  • System booted fine, but no wake from sleep.
• Then unchecked one with about 0x80 pages.
  • System booted fine, but no wake from sleep.
• The rest are very small page lengths. Have not gone through them yet.

In your case with TRX40, was it necessary to uncheck any entries with small page lengths as well as some with large page lengths?

...
You also say that you have renamed the USB controllers and mapped the USB ports with a kexts. Just trying to understand more on this but as each controller has less than 15 USB ports on it, is this necessary? (I understand why it is the case on Intel boards with the single controller and 20+ logical USB ports). If it is necessary, or optimal, then I'll have to try and work put how to do it for my MB.

One of the USB 3.0 ports on the back panel would not function with the standard DSDT port definition (XHC0). By replacing the RHUB section of XHC0, that ports works normally.

But for the other USB controller (PTXH), it may not be necessary to replace it. In fact, this is on my to-do list. Will remove both of the custom USB controller SSDTs to see whether it makes a difference for wake-from-sleep.

 

[Ploddles]

I went through the exercise of enabling/disabling from the bottom up, re-enabling ones that stopped the boot. For me that didn't fix the sleep issue, but for others it did. After more experimenting by most users it was the consensus that it was best to leave them all enabled except for the last 4. For most this allowed sleep, even a Gigabyte Designare, but alas no joy for the Xtreme.

Re the USB ports, my MB, according to Hackintool, has 2 controllers defined as XHC0, as well as others. I don't know if this is standard on AMD but it does seem a little strange to me. There is probably a good reason for it though.

 

[CaseySJ]

The Eclectic Light Company posted this blog about a potential memory leak in Catalina 10.15.6 that might still exist in Big Sur.

Catalina 10.15.6 is prone to kernel panics from a memory leak

There have been recent reports that the macOS Catalina 10.15.6 update can result in kernel panics. This appears to be common among those who run some virtualisation products such as VMWare Fusion a…

eclecticlight.co

The interesting parallels between his situation and mine:

• He experienced the same zone_map_exhaustion issues during idle time (he does not put his system to sleep, but instead leaves screen saver on). I experienced these issues after waking from sleep.
• My log contains the same sequence of events that he describes, but on different kalloc IDs.
• It seems memory appears to get exhausted so macOS begins killing processes one by one.

Additionally, removing the new XHC1 and XHC2 devices (and leaving the original ones intact -- XHC0 and PTXH) causes the same wake problem. However, all the USB ports do work! So this is a nice bonus (I can disable the two USB SSDTs and use only the USBPorts kext).

A well written explanation of kernel memory allocation (i.e. kalloc calls are made by kernel extensions [kexts]):

How a kernel zone memory leak can panic macOS

When a kernel extension wants some memory, it calls for an allocation from a Mach zone. This explains how a memory leak in those zones can result in a kernel panic.

eclecticlight.co