That's what I got today from Gigabyte about the non-working Thunderbolt 4.
"Thank you for the information I forward to TW. Until now, unfortunately, I have not received information either about the confirmation of the problem or about possible solutions. The only information I have is that the control panel needs more time for analysis."
My dialogue with Gigabyte support is similarly frustrating. They seem to be way in over their heads on this Thunderbolt 4 hot-plug support issue. At this point in their correspondence with me, they are now blaming the firmware of my devices on the hot-plug issue, even though these devices hot-plug just fine with Titan Ridge and also with an Asus z590 motherboard with Maple Ridge, NVM24.
Gigabyte has said they've tested certain Thunderbolt 3 devices, that hot-plug fine with their Z590 Vision D. But what I pointed out to Gigabyte is we need to be as clear as possible so that we can resolve the issue. Lack of clarity is part of the problem.
As I have dug into this issue some more, what I am observing is "Thunderbolt 3" is a simple term, but the reality is more complicated. So we must unpack. There are in fact various Thunderbolt 3 controllers embedded into devices on the market. As we know, there is Alpine Ridge and Titan Ridge. And within the Alpine Ridge "family" there are at least 3 different controllers in use in various peripheral devices, JHL6240, JHL6340, and JHL6540.
After testing, a pattern is emerging. Non-functional hot-plugging on the Z590 Vision D appears to apply to Thunderbolt 3 devices with Alpine Ridge JHL6240 and JHL6540 controllers inside, but not JHL6340 inside. What happens when JHL6240 and JHL6540 devices are plugged into the Z590 Vision D while the OS is running is that the Thunderbolt enclosure is recognized in Windows Thunderbolt control center, but the embedded PCIe device, such as an Aquantia AQC107, or a USB hub connected to a dock, does not receive PCIe lanes, and as such, the PCIe device fails to show up in Windows Device Manager. So the enclosure comes on, but the embedded PCIe device does not. The device becomes a zombie. On, but dead. However, my NVMe enclosure with JHL6340 actually hot-plugs just fine with the Z590 Vision D's NVM26.5. And when macOS goes to sleep and awakens, this device is not prematurely ejected. Curiously, however, at least in Windows, once Windows is put to sleep and reawakens, the Maple Ridge controller is re-initialized, and devices connected to the Thunderbolt bus that are in a zombie state, including the JHL6240 Ethernet adapter, go off briefly and come back on, and finally receive their PCIe lanes, and then operate normally. So at least in Windows, there is a pseduo hot-plug support, but only if you put Windows to sleep first, then wake it up again. Linux seems to do this too. This is unacceptable.
So rather than talking past each other, what Gigabyte needs to do is create a matrix of various Thunderbolt 3 controllers and test each to see if the various ones do in fact have hot-plug support on the Z590 Vision D, and if not then reach out to Intel. Because, the same devices with JHL6240 and JHL6540 that fail to hot-plug to the Z590 Vision D actually hot-plug successfully with Maple Ridge on a Z590 Asus Hero, so long as NVM24 is installed (and not NVM26).
So while Gigabyte has claimed to have observed functional hot-plugging with some "Thunderbolt 3" devices,
it is not enough to conclude that hot-plugging is properly working for all Thunderbolt 3 devices, given the variety of Thunderbolt 3 controllers on the market, as well as the range of Intel NVM that these devices are running. It is not clear whether Gigabyte in its tests exclusively used JHL6340 devices or Titan Ridge devices, or if they indeed tested or excluded testing devices with JHL6240 and JHL6450. If they did in fact test JHL6240 devices, were they running with a newer NVM than that of the devices we are using?
When Intel said that Thunderbolt 4 has backwards compatibility with Thunderbolt 3 I did not expect that certain Alpine Ridge devices would hot-plug, and others would not.
I have also observed that there are at least 3 versions of the Maple Ridge NVM in the wild. The Asus Hero 13 comes with NVM24, MSI has NVM26, and the Z590 Vision D has NVM26.5. With version 24 of the NVM on the Asus Hero, hot-plugging Thunderbolt 3 devices works fine regardless of if they are JHL6240,6340, or JHL6540. But Asus has BIOS updates on its website, 0605 and 0704, and nowhere in Asus' release notes do they warn the user that the BIOS update process of 0605 and 0704 will update the NVM to 26, and that there is no ability to opt-out whatsoever, and that once updated there is no way to downgrade back to 24, even if you flashback to the original BIOS. When the Maple Ridge controller on the Asus motherboard is updated to NVM26, this is a one way ticket to compatibility problems with hot-plugging certain Alpine Ridge devices, (i.e., those with JHL6240 and JHL6540) as I've mentioned above for Gigabyte.
Then there is the other issue of Gigabyte hiding certain BIOS settings from the user. As long time users of Gigabyte motherboards should be aware, Gigabyte used to hide the CFG-Lock setting, and it was enabled by default on some motherboards, meaning that that macOS would not boot without enabling a patch. By using a modified-grub boot loader, you could actually change the value of the CFG-Lock setup variable to effectively set it to 'disabled.' But Gigabyte finally added the ability to modify this setting in the Z490 Vision D BIOS after I asked them to last year (given that some of their competitors allowed the user to change this setting on some motherboards).
In order to learn what settings are there and in which setup variable, you have to extract the UEFI code within. What I have uncovered is that there are various hidden settings related to Thunderbolt hot-plug on the Zz490 Vision D BIOS that are missing from Z590, such as "ACPI Notify on TBT Hot-plug" and "SW SMI on TBT hot-plug." These variables may be hidden, but they are enabled by default on the Z490 Vision D, but are not in the Z590 Vision D BIOS. I do not know whether Maple Ridge needs these settings for hot-plug to work, it could be that Maple Ridge doesn't need these settings. But I wonder if part of the reason why the OS doesn't seem to become aware when certain Alpine Ridge devices are hot-plugged to Maple Ridge with NVM26 or NVM26.5 is because there is no ACPI signal being sent to the OS? I don't know.
Another variable that Gigabyte hides from the Z590 Vision D user is the 'Control Iommu Pre-boot Behavior.' I am not fully sure how this setting interacts with the Thunderbolt controller, but Asus notes this setting is 'to Support DMA Protection Feature.' This setting is disabled by default on the Z590 Vision D, but enabled by default on the Asus Hero 13 (at least on the original 0232 BIOS, IDK if this changed on later BIOS). The reason why this setting is important for me is because when my Goshen Ridge Thunderbolt 4 dock is connected to the Z590 Vision D at default settings, the boot process slows down dramatically, taking nearly 40 seconds to post. Gigabyte is aware of this, and has blamed the problem of slow boot on the firmware of my Goshen Ridge dock. But, when I set the 'Control Iommu Pre-boot Behavior' to 'Enable IOMMU during boot' the boot process shortens considerably, and 20-30 seconds are saved! So it doesn't appear to be a firmware issue with my dock, but rather a BIOS configuration issue with the Z590 Vision D.
Gigabyte also disables hot-plug on the root port 5 of the Z590 Vision D by default. The Thunderbolt controller is connected to root port 5 on both the Asus Hero 13 and the Gigabyte Z590 Vision D. Asus enables hot-plug on this rootport by default. Enabling hot-plug on this root port didn't fix the hot-plug issues with certain JHL6540 and JHL6240 devices, but it allows an eGPU to power one monitor while Windows/Linux boots, and the internal GPU powers the other monitor. This wasn't working before. Also Windows can now go to sleep and awaken and the eGPU is not ejected...upon waking up from sleep, the GPU'S fan spin up briefly and then spin down into to 0 RPM mode, and the connected monitor comes on! Also, enabling hot-plugging on this rootport allows for much more consistent hot-plugging support with my JHL6340 devices, as well as better performance on my Goshen Ridge dock's downstream Thunderbolt ports. Not clear why Gigabyte disables this by default, and Asus does not, or why gigabyte hides the ability for the user to modify this setting. Enabled is the way to go!
Finally, Gigabyte's z590 has a hidden menu that pertains to RGB Fusion code that appears to allow the user (if it were enabled) to control the RGB lighting of the Vision D. I am not sure why Gigabyte hides this menu from the user. It also hides this menu in its Z490 Vision D BIOS as well.
So to summarize, Gigabyte needs to:
- Test for hot-plugging support with various Alpine Ridge devices for hot-plug support. It is not enough to simply test a Titan Ridge device or a JHL6340 device and conclude that ho-tplug is working, when JHL6240 and JHL6540 devices (and possibly others) are having trouble.
- Reach out to Intel to see if there truly is an incompatibility with Maple Ridge NVM26.5 and devices with JHL6240/JHL6540, and if so, make the new firmware available for users to update Maple Ridge.
- Allow the user to enable the 'Control Iommu Pre-boot Behavior' option, as the Asus Hero allows the user to control this, so does Gigabyte's W480 Vision W, according to its manual. This setting allows for seemingly better compatibility with my Goshen Ridge device. If they allow the user of the W480 Vision W to access this setting, then why not the Z590 Vision D?
- Enable the hidden RGB fusion code in the BIOS to let us unleash the unlimited power of RGB, without needing to boot Windows.
