Contribute
Register

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

I tried searching here, but have not found a way to search just this particular thread. It pulls up info from all of tonymac. :( As a result, forgive me if this has been discussed before!

I have a Gigabyte Aorus Z390 Gaming SLI, so not exactly the same mobo as listed here. I followed the excellent instructions here and successfully completed a Hack. Audio, RX 580, LAN, Wifi, BT, etc all working. This board has all 6 USB 3.0 on the rear, 2 USB 3.1 on the rear, two USB 3.0 via mobo header and two USB 2.0 mobo header. I was doing some further testing today, and discovered that USB 3.x devices would *not* work on any of the USB 3.x ports. Tried four different USB 3.0 and USB 3.1 devices (flash drive and portable storage). The devices works fine via the USB 2.0 mobo header. USB 2.0 devices work on all USB ports.

However, if I let the computer go to sleep on it's own, upon wake-up the USB 3.x device works just fine on all USB ports! If anything, I would think the opposite would be true, and ports stop working after wake! The wake "repaired" the computer, lol! Any ideas?? TIA.
The USB SSDT in this guide is customized for the Designare Z390 so it should definitely not be used on the AORUS Z390 Gaming SLI. Instead, you may apply the three Mojave 10.14.4 USB port limit patches in Clover as described here. This should enable all ports, but the patches are specific to 10.14.4 and may not work in subsequent Mojave updates. The best long term solution is to create a custom USB SSDT for your motherboard by following this user-friendly guide:
 
I definitely did not use the one you provided. I have none included, so will take a look at the custom SSDT creation. Does the weird behavior make any sense, where it starts working after wake from sleep?
 
I definitely did not use the one you provided. I have none included, so will take a look at the custom SSDT creation. Does the weird behavior make any sense, where it starts working after wake from sleep?
I haven't observed that behavior, but if you already have the three USB port limit patches installed (they're installed by UniBeast and MultiBeast), there might be a connection. It's also useful to run IORegistryExplorer and compare the list of ports under XHC both before and after sleep. Feel free to post the two IOReg dumps (File --> Save As...).
 
I haven't observed that behavior, but if you already have the three USB port limit patches installed (they're installed by UniBeast and MultiBeast), there might be a connection. It's also useful to run IORegistryExplorer and compare the list of ports under XHC both before and after sleep. Feel free to post the two IOReg dumps (File --> Save As...).

For a quick test, I opened up the config.plist file with Clover Configurator. Under the "Kernel and Kext Patches", there are the three Port Limit Removal patches listed, which you disabled since you had your own custom SSDT file. For kicks, I unchecked these so they were enabled, and USB 3.0 devices were now working before and after sleep. This is the temporary 10.14.4 workaround you linked, which may break with next release. I tried IORegistryExplorer, but am not overly familiar with the format and what I am looking for.

This seems to hold me over for now, but I will proceed down the road with customizing a SSDT file. Thanks for the help!
 
Confused... :confused:
I am unable to boot unless I have (a) VT-d disabled in BIOS or (b) dart=0 checked in Clover or (c) DMAR table not dropped. I'll try and attach a slow-motion video to this post shortly. I can easily boot if any of the previously mentioned are reversed, but then I won't be able to install a device driver that NEED to have installed and have had installed and running with my Z270 Asus Hero 9 board (with VT-d enabled). Some devices need this feature to be able to access memory space within first 256MB of contiguous memory.


 

Attachments

  • 1F0D7C5F-36A2-455E-A63E-25B47B5B3FB2.jpeg
    1F0D7C5F-36A2-455E-A63E-25B47B5B3FB2.jpeg
    2.8 MB · Views: 78
  • 8E4002A2-A52F-4813-A0DB-BA5AF64A4D29.jpeg
    8E4002A2-A52F-4813-A0DB-BA5AF64A4D29.jpeg
    2.8 MB · Views: 78
  • B2CB1CBC-6234-4976-82E8-905B6CFF1AEE.jpeg
    B2CB1CBC-6234-4976-82E8-905B6CFF1AEE.jpeg
    3 MB · Views: 68
  • 7122402C-AF4E-4A5C-811F-4A3EBC1B1B5F.jpeg
    7122402C-AF4E-4A5C-811F-4A3EBC1B1B5F.jpeg
    3 MB · Views: 84
  • D6685504-3A89-4AE1-A536-5708DA7BC4E6.jpeg
    D6685504-3A89-4AE1-A536-5708DA7BC4E6.jpeg
    3.5 MB · Views: 96
  • E56FFBCF-B56D-4AF6-B281-8BAC1368211B.jpeg
    E56FFBCF-B56D-4AF6-B281-8BAC1368211B.jpeg
    3.2 MB · Views: 78
Last edited:
I am unable to boot unless I have (a) VT-d disabled in BIOS or (b) dart=0 checked in Clover or (c) DMAR table not dropped. I'll try and attach a slow-motion video to this post shortly. I can easily boot if any of the previously mentioned are reversed, but then I won't be able to install a device driver that NEED to have installed and have had installed and running with my Z270 Asus Hero 9 board (with VT-d enabled). Some devices need this feature to be able to access memory space within first 256MB of contiguous memory.

Just on a lark I tried enabling VT-d on my Aorus Z390 Pro (removed dart=0 and didn't drop DMAR) and it booted fine and seems to be stable. Not sure if it matters, but running F9 BIOS and have MSR 0xE2 unlocked. iMac19,1 under 10.14.4 18E2034.
 
Just on a lark I tried enabling VT-d on my Aorus Z390 Pro (removed dart=0 and didn't drop DMAR) and it booted fine and seems to be stable. Not sure if it matters, but running F9 BIOS and have MSR 0xE2 unlocked. iMac19,1 under 10.14.4 18E2034.
Interesting. I'm on F6 with Designaire which is the latest BIOS version. Not sure it's possible to get MSR 0xE2 unlocked. @CaseySJ any thoughts?
 
Interesting. I'm on F6 with Designaire which is the latest BIOS version. Not sure it's possible to get MSR 0xE2 unlocked. @CaseySJ any thoughts?
RehabMan once explained that MSR 0xE2 is a write-once lock. When BIOS initializes, it triggers the lock, which remains locked for as long as the machine is on. It cannot be unlocked except with a reboot. The only solution, if one can call it a solution, is to modify the BIOS.

When we enable AppleIntelCPUPM and KernelPM, the AppleIntelCPUPowerManagement kext is patched to avoid touching the MSR 0xE2 register. Clover auto-detects and applies power management patches as well, which we can see from the Clover log (in Terminal, type bdmesg):

0:100 0:000 Running on: 'Z390 DESIGNARE' with board 'Z390 DESIGNARE-CF'
0:100 0:000 === [ GetCPUProperties ] ==================================
0:100 0:000 CPU Vendor = 756E6547 Model=906EC
0:100 0:000 The CPU supported SSE4.1
0:100 0:000 BrandString = Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
0:100 0:000 The CPU supported turbo
0:100 0:000 MSR 0x35 80008
0:100 0:000 TSC/CCC Information Leaf:
0:100 0:000 numerator : 300
0:100 0:000 denominator : 2
0:100 0:000 Calibrated ARTFrequency: 24003201

0:100 0:000 MSR 0xE2 before patch 1E008000
0:100 0:000 MSR 0xE2 is locked, PM patches will be turned on

0:100 0:000 MSR 0xCE 08080838_F1012400
0:100 0:000 corrected FLEX_RATIO = E0000
0:100 0:000 FSBFrequency = 127 MHz, DMI FSBFrequency = 100 MHz, Corrected FSBFrequency = 100 MHz
0:100 0:000 MaxDiv/MinDiv: 36.0/8
0:100 0:000 Turbo: 47/48/48/49
0:100 0:000 Features: 0xBFEBFBFF
0:100 0:000 Threads: 8
0:100 0:000 Cores: 8
 
Back
Top