Contribute
Register

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

Inqnuam said:
should I assign automatically a random TB ID between 0 and 10 or give to users an option to enter a number by their self
Click to expand...
Default should always be 0. Because most systems have only 1 Thunderbolt controller, there is no need to randomly change the number. If someone has more than 1 controller, they should have the option to manually select an ID for that controller (from 0 to 10).
 
phrfpeixoto said:
I have that same card and a brand new unopened Magic Mouse 2. I'll test it out tomorrow.
Click to expand...

I connected the mouse with the computer with the lightning-to-USB cable and it works now!!!!

Thanks all!
 
CaseySJ said:
Default should always be 0. Because most systems have only 1 Thunderbolt controller, there is no need to randomly change the number. If someone has more than 1 controller, they should have the option to manually select an ID for that controller (from 0 to 10).
Click to expand...

I think I'll put the limit to 9, because after 9, so 10 and more we need 2 bytes.
 
hyevans said:
I connected the mouse with the computer with the lightning-to-USB cable and it works now!!!!

Thanks all!
Click to expand...
I can confirm too, its working perfectly since day one.
 
bmoney said:
Just wanted to report that my system has been working PERFECTLY with the inatek card all week.
Click to expand...

I installed my Inatek card yesterday.

Previously on HS11/HS12 through an internal hub I had:
  1. NZXT Pump Controller
  2. Corsair Lightning Node Pro
  3. Coolermaster ARGB LED Controller
  4. Fenvi T919 Bluetooth USB header
Now I have only the Fenvi T919 on HS11/HS12 and everything else running through the internal USB3 port on the back of the Inatek card, via a USB 3 to USB 2 internal cable, and using the same internal hub I was using previously on HS11/HS12.

So far, so good... but time will tell.

This has also seemingly fixed the bluetooth lag I was getting with Handoff enabled (only while I was streaming BT audio), so congestion on that hub seems to have been the reason for this!

Pretty pleased, no bluetooth lag, and no USB drop-outs so far!

Edit: Sleep still working too, and all other USB devices - Logitech webcam etc running from the Inatek
 
Inqnuam said:
I think I'll put the limit to 9, because after 9, so 10 and more we need 2 bytes.
Click to expand...
One byte can represent bus numbers 0 to 255. (0x00 - 0xFF)
 
CaseySJ said:
PXSX is an upstream PCI bridge. If you look at IORegistryExplorer and search for PXSX you may find a handful of them. Devices that connect to the PCI bus attach themselves to one of these bridges.



Think of the PCI bus as the river Thames, which we know from circling the London Eye, is lined with numerous bridges. On one side of the river is the PC itself; on the other side are peripheral devices wanting to connect to the PC. Just as bridges along the Thames connect the left and right sides, so do the PCI bridges.

On every bridge there is an entry/exit point on the left side and an entry/exit point on the right side. We can call these points the "ports" of entry and exit. On the PCI bus, the port on the left side (i.e. the computer side) is called the Root Port and there is of course one Root Port for each bridge. These are labeled RP01..RPxx (RP = root port). Then on the other side of the bridge is another port, but this port is controlled by the peripheral or add-in-card. PXSX is the generic name of this port.
Click to expand...

Thanks Casey, your explanation resonated even more as I’m a Londoner! Looking into the DriverReason more deeply however, it appears that even when the wake reason is given as due to /Network and due to /UserActivity Assertion the line below which depicts the DriverReason both have PXSX as the reason, so still points to it being a Network issue imo even if the WakeReason is now UserActivity

I think it’s time for me to pack up and just leave Find My Mac off for this Hackintosh. My previous Hack never left it’s location for 8 years, and thanks to your guide, more important things like iCloud/iMessage, Handoff, sync etc all work perfectly (which blows my mind!) so I’m now going to get some sanity back and reformat as new to 10.15.4 and then update.

My last question is around the change log. In May you made some adjustments to the .Zip file for the USB installer, namely:

The May 2020 Update - Catalina 10.15.4 Fresh Install.zip also contains these features:
  • NVMeFix.kext for improved power management of NVMe SSDs.
  • USBWakeFixup.kext and associated SSDT-USBW.aml for proper one-key wake from sleep (do not use darkwakeboot argument).
  • Boot argument igfxfw=2 to allow macOS to load its GuC (Graphics MicroCode) to the iGPU for improved clock speeds.
  • Uses OcQuirks-22 as the EFI memory driver.
  • Sets shikigva=80 instead of 16.
Click to expand...

My USB installer works perfectly but as it was created in April 2020, doesn't have the above changes. Are these above changes necessary (as my Machine, even with multiple reinstalls, is woken perfectly by my Apple Magic Keyboard or Apple Magic Mouse). If however there is even a small bit of value from including the above, is there a way I can 'edit' my USB install flash drive without having to go through the whole process again?

Thanks!
 
Current Rig (Shoutout to Casey!)
Z390 DESIGNARE |  i7 9700K |  Vega 56 8GB
Retired Rig (7 years!)
GA-Z77-DS3H |  i7 3770K |  GeForce GTX 760
** Best Practices Guide for USB 2.0 Devices **
Please do not quote this guide in its entirety. Post a link instead.
Credit: @ziggenpuss @bmoney @kellymac12 @jleahy2
​

Background:
The Designare Z390 is used by numerous professionals working in diverse fields. One group of professionals -- audio engineers and editors -- has recently suffered from highly unreliable USB connections. This group uses a number of USB 2.0 audio devices such as:
  • Roland TR-8S (with Ableton Push 2)​
  • Komplete 49​
  • Minilogue XD​
  • E-RM Multiclock​
  • iLok​
  • Softube Console 1​
  • Korg nano and keyboard​
  • etc.​
After a concerted team effort, the source of USB instability was tracked to (a) Intel's PCH-based USB controller and (b) macOS drivers that attach to this controller. A theory was postulated:
  • Will the instability problems disappear if USB 2.0 devices were to be connected to a different USB controller?
  • Will the instability problems disappear if USB 2.0 devices were connected to a USB 2.0 powered hub, which was then connected to the motherboard exclusively via one of the two black USB 2.0 ports (HS09 and HS10)?
After acquiring needed components, the team confirmed both elements of the theory. We can therefore publish a Best Practices Guide for audio engineers and editors who rely on USB 2.0 devices.

Best Practices:
There are two solutions to the problem of USB 2.0 connection instability.

Solution 1: Use of self-powered USB 2.0 hubs
Solution 2: Use of USB PCIe add-in-card
  • Connect all USB 2.0 devices into the ports of an Inateck PCIe add-in-card. USB 2.0 hubs may be used if more ports are needed.
  • The Inateck KT 4006 and KT 4004 have been tested, and both are plug-and-play compatible.

References:
 
Last edited:
CaseySJ said:
Empirical is how we "solve" many Hackintosh issues -- also known as trial and error. The list of experiments/variations below is quite respectable.

Looks like we've narrowed it down to NVMeFix and USBWakeFixup. This is what they do:
  • NVMeFix improves power management on non-Apple NVMe SSDs. This can be important because as we all know, NVMe SSDs can get very hot. Many motherboards provide built-in heatsinks (including Designare Z390).
  • USBWakeFixupallows the system to wake-from-sleep with just one keypress -- and to do it the right way.
    • This kext works in conjunction with SSDT-USBW.aml.
It is perfectly okay to remove all three of these files: two from kexts/Other and one from ACPI/patched. Then see if the revised May 2020 Update can boot Mojave.
Click to expand...
Hi,
finally, after trying some configurations of the EFI folder, I installed macOS Catalina 10.15.5 in a second APFS volume in multiboot configuration, on the same system drive on which macOS Mojave 10.14.6 is already installed.
To do this I had to exclude, because they made it impossible to start macOS Mojave 10.14.6, from the installation only the files:
USBWakeFixup
SSDT-USBW.aml
in the may 2020 Update - catalina 10.15.4 Fresh Install.zip package provided in Your "Fresh Installation of Catalina 10.15.4 and Newer guide".
I also updated all files:
- virtualSMC
- Lilu
- AppleALC
- WhateverGreen
- NVMeFix
- IntelMausi
to the latest version available it seems without experiencing problems in both Mojave and Catalina
However, I noticed exiting the system in macOS Catalina (both in the shutdown and in the restart) a different behavior than in macOS Mojave:
while in macOS Mojave selecting shutdown or restart from the main menu bar, after confirmation, the desktop immediately disappears and the screen turns black for a moment with a spinning wheel before the machine is physically shut down, exiting from system in macOS Catalina the desktop remains visible until the machine is completely turned off.
Is this the correct behavior for macOS Catalina?
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top