Contribute
Register

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

I think it's my cable. I tried it on my MBP and, it fails to work on that too. I'll have to try to find a cable that works, and report back.

Interestingly enough, not to shoot myself in the foot here, but I haven't had any issues since I've switched to that other EFI setup, although... I have been rebooting into Windows for a few hours every night. I think I tend to see issues when I leave the system in OSX running for days at a time more so than not.

What's the difference between your current EFI setup and the previous one? I'd be lucky to leave the system running for a day without a USB crash
 
What's the difference between your current EFI setup and the previous one? I'd be lucky to leave the system running for a day without a USB crash
A surprising amount actually. Different DSDT, only using the SSDT for TB3 and NVRAM. This one is using a different USB kext as well (or at least it's named differently). It's *drastically* more simplified as well - way less things are checked, edited, filled out, etc. I suspect the DSDT is doing more on this EFI setup than with the one on this tread which would account for less fixes being checked, etc, but I really don't know. I don't really know if that's a good thing, or a bad thing. I know enough about this stuff to get the system functional, but not all the intricacies of everything. All of this may be considered "wrong and bad practice" for all I know, but...I haven't had a USB dropout for around a week now.

I won't be convinced it's fixed/actually gone though I can leave the system up for a solid 1-2 weeks at least, while digging hard into Ableton and not experiencing the issue.
 
A surprising amount actually. Different DSDT, only using the SSDT for TB3 and NVRAM. This one is using a different USB kext as well (or at least it's named differently). It's *drastically* more simplified as well - way less things are checked, edited, filled out, etc. I suspect the DSDT is doing more on this EFI setup than with the one on this tread which would account for less fixes being checked, etc, but I really don't know. I don't really know if that's a good thing, or a bad thing. I know enough about this stuff to get the system functional, but not all the intricacies of everything. All of this may be considered "wrong and bad practice" for all I know, but...I haven't had a USB dropout for around a week now.

I won't be convinced it's fixed/actually gone though I can leave the system up for a solid 1-2 weeks at least, while digging hard into Ableton and not experiencing the issue.

Would you mind sharing your (sanitised) EFI? I'm up for trying "bad practice" if it improves stability!
 
Understood. Seems like an issue with Clover 5xxx. The problem can be reported to the developer on GitHub:

The May 2020 Update includes new versions of the UEFI memory driver (OcQuirks/OpenRuntime) and newer Acidanthera kexts (Lilu, WEG, AppleALC, VirtualSMC). It also includes USBWakeFixup and its companion SSDT called SSDT-USBW.

I suspect that the new UEFI memory driver may not be compatible with Mojave. We can, however, update the Acidanthera kexts, but leave the UEFI memory driver alone.
Unfortunately perhaps there is a "cross" problem between the inability to use the "May 2020 Update - Catalina 10.15.4 Fresh Install" package to start macOS Mojave and the problem in starting Linux using the Catalina 10.15.4 Fresh package install.
In fact, by using the "May 2020 Update" package to start, I can correctly start Linux from the Clover menu but not macOS Mojave and vice versa as regards the 10.15.4 Fresh Install package.
Therefore it seems, if I understand correctly, that these problems depend on the various versions of the same OcQuirks package, as you had guessed.
Do you think there may be a solution (or wait next OcQuirks drivers release)?
 
Last edited:
Thanks! If you do run into USB stability problems after moving some devices to on-board ports, please let us know.

Update:
I moved some of my USB devices from my TB3 dock to the Designare USB ports (both back and the case front) and tested them for several hours. They include Camlink 4K, WD SSD 2TB, Samsung EVO SSD, M-Audio Motu Audio Interface (USB 2.0 disguised with USB-C connection), Midi Keyboard Controller, all requiring pretty steady power from the ports. None of them experienced any sort of instability. I was editing some video off my SSDs and they all worked flawlessly. So this instability issue some users are experiencing may not be related to hardware. FYI, I am running Opencore 0.5.9 with Catalina 10.5.5 SUP. All the ports have been mapped using USB Map Tool from OC Desktop Guide, and I created my custom SSDTs using SSDTTime in Windows 10. What's even more interesting is that I have experienced more KP and random restart on my 2016 MPB running the same OS. I've also had my MBP flickering into black screen when connected to my 4K monitor via Caldigit TB dock, but this has never happened on my Hackintosh. It's been super stable. So, unless our motherboards have some different versions of controllers that are causing instability, it may be related to ACPI issue. Don't give up. I've attached my EFI folder for your reference.
 

Attachments

  • EFI.zip
    2 MB · Views: 81
Would you mind sharing your (sanitised) EFI? I'm up for trying "bad practice" if it improves stability!

I'm not sure if it will or not in your case, but I'd definitely be interested to hear your experience with it compared to your current EFI to see if there's any discernible difference or improvements of any kind. The DSDT may not align properly with your system though, as it was built for mine, I dunknow. Again, there very well may be 'bad practices', etc inside here so... I'd consider this nothing more than just experimental at this point.


Casey - My apologies if this isn't allowed or you don't want this up. Please feel free to remove the file if so.
 

Attachments

  • EFI.zip
    3.2 MB · Views: 85
...
Casey - My apologies if this isn't allowed or you don't want this up. Please feel free to remove the file if so.
This is perfectly okay. I would also like to see if we as a group can either (a) find the cause of USB instability or (b) use a magical EFI that prevents the problem.

Because I don't have the same types of USB devices, I'm mostly a spectator. But if we (as a group) find a solution or workaround, I will need to incorporate that into the build guide.
 
@verendus @jleahy2 @CaseySJ Thanks all. Not going to be able to do much this weekend, but I'll try out various permutations on Monday and see if any one option works better than another.
 
Correction :) : my system has iGPU disabled, so only using the Vega 64, and I get to do very quick HEVC and H.264 de- and encoding. VDA Decoder is 'fully supported' according to Hackintool.

Late reply, but I think there is a broad misconception that turning off iGPU and enabling hardware encoding will speed up rendering and export especially in H.264 and HEVC. I know many users have chosen iMacPro1,1 SMBIOS for this reason and disable their iGPU. It may be worthwhile to spend some time to test this in real life. Video export in FCPX or Resolve involves two steps. One is rendering and the other is encoding. Rendering, if background rending is turned off, could benefit from a powerful GPU as it relies mostly on GPU, but, if you have the horsepower, you should utilize background rendering. But, the encoding portion of the export is mostly CPU dependent as this is a sequential process. Software can only process timeline sequentially, so this is where multithreaded CPU will speed up the process. The only exception to this sequential encoding process is QuickSync. Intel offers the IGPU to perform certain encoding functions on the side, significantly enhancing the export time. Close to 5x with QuickSync compared to CPU alone. This is why iMac with iGPU exports HEVC or H.264 faster than MacPro. This is where T2 chip comes in to help those new xeon ImacPro's without iGPU.

Just to illustrate this, do a simple H.264 or HEVC export, and monitor your CPU and GPU usage in Activity Monitor. You will see only a small portion of that process utilize GPU over 50%. The rest is your CPU trying to take a group of pictures and encode them to the right codec. Since CPU can only work with a group of pictures, this process gets spread out through the available threads of your CPU. This is why CPU never come to load during this process as it is limited by the sequential nature of video. Your GPU pretty much sits idle except for the rendering portion of the process. Now, Adobe Premier is a complete different story, and hardly utilizes the power of GPU, and takes a different approach to the utilization of CPU, and will max out on the load. FCPX And Resolve have much more balanced approach and hence almost 4-5x times faster in export.

So if you have a powerful GPU, you may gain some speed during the rendering portion of H.264 Export, but you will lose significant time during the sequential encoding process without QuickSync. This is the reason why people with iGPU should consider using iMac19,1 SMBIOS and put it in headless mode (as that is how iMac‘s utilize iGPU) if you do H.264/265 encoding in FCPX with background rending turned on. That way you will cut significant time during export.
 
Last edited:
Back
Top