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

[Bansaku]

*** WAKE FROM SLEEP IS WORKING! ***
But there's a catch.​

...

^ is as far as I have gotten, as well most of the AMD OS X community. Frustrating isn't it? So close and in your grasp yet the solution still alludes us.

Alternative 2:

• Find a way to make sleep work even with PO9, PO10, PO11 turned on.
• Will this require patching the AppleUSB20XHCIPort function in the appropriate kext?

^ is what I have been thinking for months now, it's just that the knowhow is beyond my knowledge. I am SO GLAD TMX86 laxed the rules on AMD, simply because I know that a solution would be found here.

 

[CaseySJ]

^ is as far as I have gotten, as well most of the AMD OS X community. Frustrating isn't it? So close and in your grasp yet the solution still alludes us.

Alternative 2:

• Find a way to make sleep work even with PO9, PO10, PO11 turned on.
• Will this require patching the AppleUSB20XHCIPort function in the appropriate kext?

^ is what I have been thinking for months now, it's just that the knowhow is beyond my knowledge. I am SO GLAD TMX86 laxed the rules on AMD, simply because I know that a solution would be found here.

Regarding the question about patching AppleUSB20XHCIPort, here's an initial look at the problem. First, let's look at the log messages once again...

kernel: (AppleUSBXHCI) 000097.916083 PO9@00900000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.916094 PO9@00900000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0e000e63)
kernel: (AppleUSBXHCI) 000097.917338 PO10@00a00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.917349 PO10@00a00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000e63)
kernel: (AppleUSBXHCI) 000097.918603 PO11@00b00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.918614 PO11@00b00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000663)
kernel: (AppleUSBXHCI) 000097.966204 PO9@00900000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.966211 PO9@00900000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0e000e63)
kernel: (AppleUSBXHCI) 000097.969157 PO10@00a00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.969167 PO10@00a00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000e63)
kernel: (AppleUSBXHCI) 000097.970407 PO11@00b00000: AppleUSB20XHCIPort::resume: timeout waiting for U0
kernel: (AppleUSBXHCI) 000097.970417 PO11@00b00000: AppleUSB20XHCIPort::resume: unexpected non-U0 link state (PORTSC 0x0a000663)

...and decode some of these fields:

• 000097.916083 -- this column appears to be the elapsed time since wake in micro seconds? Regardless, it is a measure of time.
• PO9@00900000 -- this consists of two parts: PO9 is the USB port name and 00900000 is its address in the USB bus.
• AppleUSB20XHCIPort -- this is the name of the class in the source code.
• ::resume -- this is the name of the class member function in the source code.
• timeout waiting for U0 and unexpected non-U0 link state are of course the description strings.
• 0x0a000663 and 0x0a000e63 are link state values.

The class AppleUSB20XHCIPort is in the kext AppleUSBXHCI, which in turn exists in the kext /System/Library/Extensions/AppleUSBHostFamily.kext/Contents/Plugins.

When we open AppleUSBXHCI in Hopper Disassembler, we can locate the entire AppleUSB20XHCIPort class and narrow in on the resume member function. We can further convert the assembly code into pseudo-code and find the exact location where these messages are captured into the system log file:

From our earlier work on Titan Ridge Thunderbolt Bus activation using SSDT (not flashing), we found that Link State would start off normally (link states 0x2, 0x7, 0x101) but would flip to an inactive and/or error state within 20 seconds after boot. That inactive/error state had a very similar value (0xe00002eb) to what we see here.

So it seems that the USB 2 port itself is not moving into a proper Link State after wake-from-sleep. Because of the bad state, the system subsequently fails to wake fully.

A fix for this problem would be to understand how to control USB 2 ports at the register level and set them to the right active state.

Speculation Zone:

• It seems as if the USB driver is not doing this correctly -- maybe because AMD's USB host controller behaves differently from Intel's?
• Alternatively, we know that Intel's USB implementation has been quirky. So if macOS is handling those quirks in an Intel-specific way, then those quirks may not be working on non-Intel chipset-based USB controllers.
• I wonder if USB 2.0 drivers from Linux can be ported to macOS in the same way that Intel WiFi and Intel Bluetooth drivers from Linux are being ported...
• Again, this is speculation -- but that's all we have right now.

 

[CaseySJ]

The Fenvi BCM94360NG link in Post #1 is from Amazon US. If you use "amazon.de" or something else, the link will not work. If you're outside the United States, please go to your Amazon home page and enter this in the Search Box:

BCM94360NG

 

[CaseySJ]

Big Sur Public Beta 4 on the B550 Vision D: (this time for real )

Build # 20A5374i
Needed the latest experimental AMD 17H patches from the "experimental-opencore" branch.

 

[DJ4MC]

Man, you are making me want to go place an order with Newegg... Although realistically my Z390 will last easily another few years. I'm editing 4K video like cutting butter. And as you mentioned, Thunderbolt is a necessity to be a Mac. It is interesting that apple is going to their own silicon just after releasing the MacPro with maxed out intel. The next few years will be fun. I notice you are running the B550 as a iMac Pro, is there a specific reason for that?

 

[CaseySJ]

Man, you are making me want to go place an order with Newegg... Although realistically my Z390 will last easily another few years. I'm editing 4K video like cutting butter. And as you mentioned, Thunderbolt is a necessity to be a Mac. It is interesting that apple is going to their own silicon just after releasing the MacPro with maxed out intel. The next few years will be fun. I notice you are running the B550 as a iMac Pro, is there a specific reason for that?

The Z390 is still the benchmark! Its flashed Thunderbolt controller remains the most problem-free out of all the others that we've tried. There will always be something bigger and better "coming soon" so we must not succumb to those temptations!

Because I'm supporting an audience that has grown to include AMD Ryzen owners, it was somewhat incumbent upon me to build or attempt to build a benchmark system based on the Ryzen processor.

 

[trs96]

Although realistically my Z390 will last easily another few years. I'm editing 4K video like cutting butter.

I would keep using Z390 for now and see how the Ryzen/AMD support has evolved in a few years. You may get even more bang for your buck by then.

 

[Ploddles]

Good evening (here in the UK) or morning (for you in California) @CaseySJ

I have seen your post re getting sleep working by disabling a few USB ports.

When I boot Catalina and run IORegistryExplore and save the file I get a significantly different file size than when I run it on Big Sur (about 4MB difference).

When I then run Hackintool and have a look at the USB section, again there is a massive difference between Catalina and Big Sur. All with the same OC 0.6.1 config.plist (no USB related SSDTs loaded).

The first image below is from Big Sur and the other 2 from Catalina - it needed 2 images to be able to see all the listing in Catalina.

Do you know if this is expected or is there a (big?) problem somewhere with my system?

Thanks for any light you can shed on this.

 

[CaseySJ]

@Ploddles,

Because your screenshots are from an AMD Ryzen system (Threadripper?), are you using only USBPorts.kext, but no USB SSDT at all?

• Without an SSDT, an AMD motherboard will generally define XHC0 and XHC1. We can see this in the Big Sur screenshot.
• But in the Catalina screenshot we see a phantom XHC. AMD systems generally don't have this. Instead, depending on circumstances, we use an SSDT to create XHC in place of either XHC0 or XHC1.
• If you can provide your USBPorts kext, I can at least if there's anything unusual there.

 

[Ploddles]

Thanks for your reply. Yes, it is the Threadripper.

I don't currently have a USBPorts.kext, or SSDT for the controllers. It was my intention to create the kext, as I am clueless re SSDTs to rename the controllers. But, as Catalina and Big Sur showed so much difference in Hackintool I wasn't sure which was right or if there is something else I am missing.