Contribute
Register

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

Some of these devices are known to cause sleep problems in macOS. You haven't stated the makes/models of these devices so all I can suggest it to connect Bluetooth (which provides a function) and disconnect RGB (which provides a fashion).
I would have done so, but these devices cost a lot of money and I would like everything to function as expected cooler gigabyte ATC700
Case gigabyte C300 Glass
 
I would have done so, but these devices cost a lot of money and I would like everything to function as expected cooler gigabyte ATC700
Case gigabyte C300 Glass

As this is Hackintoshing, you can't have the best of both worlds. You have to choose which is more important to you, sleep or flashing lights - you can't have both.
 
As this is Hackintoshing, you can't have the best of both worlds. You have to choose which is more important to you, sleep or flashing lights - you can't have both.
if it is impossible to solve it programmatically, then I will solve it differently
 
if it is impossible to solve it programmatically, then I will solve it differently
Does the ATC700 contain a USB connector?
  • Because it supports RGB Fusion, it should be connectable to any RGB Fusion header (3-pin Addressable RGB) on motherboard (Z390 Designare does not have this).
Or does the Gigabyte C300 Glass contain a RGB lighting controller into which the ATC 700 is plugged?
  • If so, is the RGB lighting controller connected via USB to the F_USB header on Designare?
One workaround is to connect the RGB lighting controller to an External USB port on the rear IO panel. We can use a 9 pin USB to USB 2.0 cable to do this. Then if you run IORegistryExplorer and export the IOReg file (File --> Save As...), we can help you disable that external USB port in macOS. This allows Windows to control RGB effects, but hides the device from macOS.
 
Does the ATC700 contain a USB connector?
  • Because it supports RGB Fusion, it should be connectable to any RGB Fusion header (3-pin Addressable RGB) on motherboard (Z390 Designare does not have this).
Or does the Gigabyte C300 Glass contain a RGB lighting controller into which the ATC 700 is plugged?
  • If so, is the RGB lighting controller connected via USB to the F_USB header on Designare?
One workaround is to connect the RGB lighting controller to an External USB port on the rear IO panel. We can use a 9 pin USB to USB 2.0 cable to do this. Then if you run IORegistryExplorer and export the IOReg file (File --> Save As...), we can help you disable that external USB port in macOS. This allows Windows to control RGB effects, but hides the device from macOS.
Thank you very much for your help, the case and cooler have usb and both are connected to f_usb, tomorrow I will find out which of them does not let the computer fall asleep and let you know
 
I know that Apple TB displays aren't supported here, but I thought CaseySJ might have had another high-intensity workout this morning, haha.
On my Z390 Aorus Pro, I am using an unflashed GC-Alpine Ridge. I'm using the AR SSDT from HackinDROM, which is attached.

After either a cold or warm boot, the display and its USB functions (camera, display audio) work fine. Upon wake from sleep, I get a notification that one of the USB devices is using too much power and USB ports have been disabled. What gets disabled are the display USB functions and the USB 2 internal hub to which are connected the 4 rear USB ports.

I certainly can live with this, as I have plenty of other USB ports so as to not have to use the USB2 ports, and I have a webcam connected in case I need to have camera and no time to reboot (such as very important FaceTime from my grandson!!).

Attached are IOReg from a warm boot, IOReg upon wake from sleep, and the SSDT I'm using.

What I was hoping is that there is some control over USB power that could be tweaked to tell OS not to worry.

Thanks.

Screen Shot 2021-02-12 at 10.32.39 AM.png
.
 

Attachments

  • SSDT-TB3-HackinDROM.aml
    2.1 KB · Views: 39
  • IOReg after bootup.ioreg
    7.8 MB · Views: 29
  • IOReg after wake.ioreg
    8.3 MB · Views: 28
I know that Apple TB displays aren't supported here, but I thought CaseySJ might have had another high-intensity workout this morning, haha.
As luck would have it, I did in fact have another high-intensity working this morning! So I suppose a proper response is justified...

On my Z390 Aorus Pro, I am using an unflashed GC-Alpine Ridge. I'm using the AR SSDT from HackinDROM, which is attached.

After either a cold or warm boot, the display and its USB functions (camera, display audio) work fine. Upon wake from sleep, I get a notification that one of the USB devices is using too much power and USB ports have been disabled. What gets disabled are the display USB functions and the USB 2 internal hub to which are connected the 4 rear USB ports.

I certainly can live with this, as I have plenty of other USB ports so as to not have to use the USB2 ports, and I have a webcam connected in case I need to have camera and no time to reboot (such as very important FaceTime from my grandson!!).

Attached are IOReg from a warm boot, IOReg upon wake from sleep, and the SSDT I'm using.

What I was hoping is that there is some control over USB power that could be tweaked to tell OS not to worry.

Thanks.

View attachment 508989
.
Because these USB ports are remote devices hidden behind a Thunderbolt controller running inside the monitor itself, we don't have ACPI (SSDT) control over them like we do with motherboard USB ports.

If you have a real Mac with Thunderbolt ports, does the problem occur there as well (after waking from sleep)?

There is more to the Thunderbolt Monitor story than we've tackled in the past, but it gets quite complicated. A simple description of it goes like this:
  • Real Macs configure Thunderbolt monitors with firmware (BIOS). They contain a handful of Thunderbolt EFI drivers that manage those monitors from the earliest stages of system startup to the point at which macOS takes over.
  • These drivers also send configuration details to macOS through "Device Path Properties". This allows macOS drivers to seamlessly take over and manage those components more effectively.
  • Hackintoshes do not contain any of this capability. Some motherboard BIOSes are better than others at managing Thunderbolt peripherals, but none provides the same level of functionality as Apple's own firmware.
This is part of the reason we often say that Thunderbolt device behavior on a Hackintosh should mostly be taken on an as-is basis. Apple owns all the source code, of course, so they have the power to fix anything. But we on the other hand have to make the most of the hand we're dealt.

However, let me ask whether disconnecting and reconnecting the Thunderbolt monitor fixes this problem after wake-from-sleep?
 
As luck would have it, I did in fact have another high-intensity working this morning! So I suppose a proper response is justified...


Because these USB ports are remote devices hidden behind a Thunderbolt controller running inside the monitor itself, we don't have ACPI (SSDT) control over them like we do with motherboard USB ports.

If you have a real Mac with Thunderbolt ports, does the problem occur there as well (after waking from sleep)?

There is more to the Thunderbolt Monitor story than we've tackled in the past, but it gets quite complicated. A simple description of it goes like this:
  • Real Macs configure Thunderbolt monitors with firmware (BIOS). They contain a handful of Thunderbolt EFI drivers that manage those monitors from the earliest stages of system startup to the point at which macOS takes over.
  • These drivers also send configuration details to macOS through "Device Path Properties". This allows macOS drivers to seamlessly take over and manage those components more effectively.
  • Hackintoshes do not contain any of this capability. Some motherboard BIOSes are better than others at managing Thunderbolt peripherals, but none provides the same level of functionality as Apple's own firmware.
This is part of the reason we often say that Thunderbolt device behavior on a Hackintosh should mostly be taken on an as-is basis. Apple owns all the source code, of course, so they have the power to fix anything. But we on the other hand have to make the most of the hand we're dealt.

However, let me ask whether disconnecting and reconnecting the Thunderbolt monitor fixes this problem after wake-from-sleep?
thanks for taking a look at my question.

when connected to a MacBook Pro, the display works properly after wake from sleep.
on the Aorus pro, unplugging/replugging the display doesn't bring back the USB ports.

as I said, I have an acceptable workaround.

thanks
 
Back
Top