[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[CaseySJ]

That’s what I did.

Apparently, the OS will also adjust depending on this setting. It affects how the PCH lanes are managed, and also supposedly the timings and latencies of the graphics and other PCI-E devices. I’m no expert on that though.

The RW/O registers (Read/Write Once) are those that can be read any time, but written (modified) only once after each reboot. As soon as firmware (BIOS) writes to that register, it cannot be written-to again until the next reboot. So if you change IOAPIC 24-119 to Disabled, then changing it back to Enabled will undo the modification after each reboot.

MSR 0xE2 (CFG-LOCK) behaves the same way. It's also a write-once register, which is why BIOS has to either write a "1" or a "0" to it every time the system boots (i.e. the setting does not persist between reboots).

 

[bugsyraz]

The IORegistryExplorer screenshot does not look correct. Under RP05 you should see the following (in the absence of any connected Thunderbolt device):

View attachment 460305

Suggestions:

1. Do not use the "search" field in IORegistryExplorer. Just scroll the device tree on left side until you see RP05. Do you still see a reduced list of devices compared with screenshot above?
2. Confirm that CLOVER/ACPI/patched no longer contains the file: SSDT-Z390-DESIGNARE-TB3HP-V4.aml
3. Re-read the Winbond chip with Raspberry Pi three times, compute checksums three times, and see if they match the checksum of DESIGNARE-Z390-NVM33-Elias64Fr.bin (shown below)

% shasum DESIGNARE-Z390-NVM33-Elias64Fr.bin
edbbe3cbf8e3fa4a9d991e0681f2a5702b248224  DESIGNARE-Z390-NVM33-Elias64Fr.bin

Hi Casey,

I've managed to reflash the chip after a bunch of tries.

Initially reflashed it back to the backed up original firmware. Then went ahead to check functionality in Windows and it won't see the ports at all. Curiously enough, USB-C devices worked while with Elias's firmware, USB-C wasn't working.
Thunderbolt didn't work though. I can see it in Device Manager but ports are not seen.

Went back and reflashed it to NVM33, checksum was good.

Booted back to OSX and Thunderbolt BUS shows the same thing.

Also worth mentioning, USB-C doesn't work on OSX either, with NVM33 installed.

Here's a picture of IOREG.

 

[CaseySJ]

Hi Casey,

I've managed to reflash the chip after a bunch of tries.

Initially reflashed it back to the backed up original firmware. Then went ahead to check functionality in Windows and it won't see the ports at all. Curiously enough, USB-C devices worked while with Elias's firmware, USB-C wasn't working.
Thunderbolt didn't work though. I can see it in Device Manager but ports are not seen.

Went back and reflashed it to NVM33, checksum was good.

Booted back to OSX and Thunderbolt BUS shows the same thing.

Also worth mentioning, USB-C doesn't work on OSX either, with NVM33 installed.

Here's a picture of IOREG.View attachment 460366

Please post the following:

• IORegistryExplorer --> File --> Save As... (post this file)
• Compressed CLOVER folder (but remove serial numbers from config.plist)

 

[bugsyraz]

Please post the following:

• IORegistryExplorer --> File --> Save As... (post this file)
• Compressed CLOVER folder (but remove serial numbers from config.plist)

Here you go, Casey!

Thanks!

 

[CaseySJ]

Here you go, Casey!

Thanks!

That folder must be deleted.

 

[bugsyraz]

That folder must be deleted.

View attachment 460373

Sure, tis done.

 

[CaseySJ]

Sure, tis done.

Is the Thunderbolt tree still truncated in IORegistryExplorer? Please try a cold boot:

• MacOS --> Shutdown
• Then flip power switch on PSU to OFF for 10 seconds
• Restart

 

[bugsyraz]

Is the Thunderbolt tree still truncated in IORegistryExplorer? Please try a cold boot:

• MacOS --> Shutdown
• Then flip power switch on PSU to OFF for 10 seconds
• Restart

Yes, Thunderbolt tree is still truncated. Trying a cold boot now.

EDIT: Tried a cold boot, results are the same. I wonder if something might have happened to the chip.

It's weird enough that after reflashing back to the original firmware, it still wasn't working.

Is there a way to check if the chip is fried?

There's also a very weird thing that happens after a while, when OSX is running. The system freezes completely and while that happens, it sends a weird white noise pattern type sound to the monitor's speakers. Reset button doesn't work, i have to force shut down. Worth mentioning that the default sound output isn't the monitor, it's my external USB sound card and internal audio is disabled.

LATER EDIT: Realized the freeze with the sound issue was caused by the XMP (Extreme memory profile) in BIOS, which was set to Profile 1 (2666 Mhz). Set it back to default, system is stable again.

 

[RuleBreaker01]

Couple of suggestions:

1. Boot from your bootable backup disk and see if the connection problem is still present. If the problem is not present, it means something most likely changed in the main macOS disk. But if the problem occurs with the backup disk as well, then perhaps something has changed on the NAS or the Ethernet switch. Are you using a managed or unmanaged switch/hub?

2. Check if anything has changed on the NAS systems. New firmware might have been auto-installed. Or SMB password or allowed-access-lists might have changed.

3. Check hub/switch configuration if it’s a managed switch.

I finally got a chance to get in a full troubleshoot.

1. Problem wasn't isolated, same issue occurred on backup disk.
2. Verified no recent changes on servers.
3. It is a managed switch, brocade ICX6610. Settings are as they should be.

That being said, I did discover/uncover the underlying issue. There seems to be some form of incompatibility with selecting jumbo frames is system preferences/network. This has never posed an issue prior to now. I was always able to select MTU 9000, and operate accordingly. With 9000 MTU, various LAN addresses are inaccessible via all browsers, connection issues over SMB and AFP (finder will free while connecting, freeze while accessing/transferring, generally slow SMB and AFP transfers, mounted ISCSI volumes dropping, mounted SMB shares disconnecting seemingly at random.

As seen in the pictures, 9000 MTU will not autoselect, so I have to select the pictured settings to see Jumbo frames as an option. With the pictured settings, 1500 MTU selected, expected operation. Jumbo frames selected, the issues occur. When I select Custom, enter 9000 MTU changes will not save. When I select Custom, enter (the max) 10222 MTU changes will not save. (note on Custom: I am able to hit save, then apply in the network settings, however the changes applied do not stick. When I return to configuration, the MTU is reset to 1500.

With MTU set to 1500, it at least appears to be workable. I just discovered this issue, so have not been able to fully test. But I can access all LAN locations, SMB shares seem to be stable. SMB shares are underperforming, in limited trial, but have historically with 1500 MTU selected. So, I'd like to figure a way past this issue, and get back to optimal network settings, as some of my use-case is high-performance-dependent.

I will also note when the NIC's are plugged in, with no changes, literally unplug from this workstation, pluginto macbook pro, plugged into rackmount mac pro, no issues whatsoever. So, seems contained to customac only. I've tried two different Chelsio T4 NIC's, Two different (same model) T5 NIC's, and one T6 NIC, with the same results. NIC firmware is the most recent, Catalina approved. Most recent catalina kext is installed.

I'm seeing if it may be a chelsio issue, i've reached out to their support. But, curious if any further insight can be given. I wish i had access to another mac compatible 10GbE+ NIC, but can't get my hands on any other brand, due to current availability.

 

[FormerUser-50757]

The RW/O registers (Read/Write Once) are those that can be read any time, but written (modified) only once after each reboot. As soon as firmware (BIOS) writes to that register, it cannot be written-to again until the next reboot. So if you change IOAPIC 24-119 to Disabled, then changing it back to Enabled will undo the modification after each reboot.

MSR 0xE2 (CFG-LOCK) behaves the same way. It's also a write-once register, which is why BIOS has to either write a "1" or a "0" to it every time the system boots (i.e. the setting does not persist between reboots).

I guess my point is that maybe the OS after booting with it set to disabled makes some changes that somehow fix something. Could that be a thing?

Edit:
Or maybe the graphics card and/or other PCI-E devices get tweaked somehow. Before when I would change the x4 slot mode to the CPU side, my graphics would bench 10k higher in Geekbench, which is weird because that's supposed to to only leave the top x16 slot with 8 lanes instead of 16. I just tested this setting again, and now it lowers my benchmark scores (as it should I'm guessing.)

Unlocking the MSR affects how NVRAM works, so perhaps this BIOS setting also affects the OS at the system level. If anyone else is having issues like me (seems like there are more than few) they could try this and test it out to see if it's a thing/solution.