GTi15 Ultra USB4 problem with Proxmox 9.2

lukeH

The USB4 port on the GTi15 Ultra 285H does not work at all on Proxmox 9.2 (based on Debian 13).
I have tested both the Ugreen 40Gbps SSD enclosure (based on the ASM2464PD) and the Ugreen 80Gbps model (based on the JHL9480). The enclosure powers down at the start of the Proxmox boot process—immediately after GRUB—and is not recognized by the operating system.
My GTi15 Ultra is running BIOS version T202. Since all other Proxmox functions work perfectly, I am concerned that a BIOS update might introduce new issues. However, in its current state, the 40Gbps USB4 port is completely useless; this is a serious problem, as it prevents the use of high-speed external SSDs.
I would like to know if a BIOS update is necessary and which version has been fully validated. I have read in other discussions about users experiencing issues—such as Ethernet port problems—after updating the BIOS (possibly due to a regression), as well as reports of critical errors with various Linux distributions.
I would also like to know if it is possible to downgrade the BIOS should further issues arise.
I would appreciate any up-to-date information anyone can provide.

Beelink CS-Lynn

lukeH
Sorry for the inconvenience.
Please send us a photo of the serial number (SN) located on the bottom of the PC, as well as a photo of the purchase record showing the product model, store name, purchase date, and order number.
Does the USB4 port work properly on other operating systems, such as Windows?
We will relay this issue to our technical staff and get back to you once we receive a response.

sulaxna068debi

a problem with the SSD enclosures, especially since you tested both ASM2464PD and JHL9480 devices. I’d avoid flashing the BIOS blindly and first check with Beelink whether a specific BIOS version has been validated with Proxmox 9.2.

lukeH

Dear Beelink Support Team,
First of all, I would like to thank you for your support and congratulate you on the Beelink GTi15 Ultra (Intel Core Ultra 9 285H). It is an outstanding machine, and almost everything works flawlessly under Proxmox VE (Debian 13), including the excellent dual 10Gbps Ethernet ports.
However, I am contacting you regarding the 40Gbps USB4 port, which exhibits an ACPI/firmware-related issue when trying to use high-speed external enclosures under Linux.
Following your previous suggestion to verify if the port might be physically defective, I conducted rigorous troubleshooting sessions and performed a benchmark using a native USB-C external drive (Transcend ESD310S).
Here are the concrete findings that prove the hardware port is 100% functional, pointing instead to a BIOS / ACPI compliance bug:

Hardware Verification (10Gbps Mode Works Perfectly):
Under Linux, the Transcend ESD310S successfully and stably negotiates full 10000 Mbps (USB 3.2 Gen 2) via the UAS (USB Attached SCSI) driver. Direct sequential write benchmarks (dd with oflag=direct) yielded a rock-solid throughput of 840 MB/s. This mathematically proves that the Type-C port data lines, controller, and power delivery are working flawlessly at the hardware level.
The 40Gbps USB4 Bug:
The issue occurs only when connecting a true 40Gbps USB4/Thunderbolt enclosure (such as an ASMedia ASM2464PD based device). The drive receives power and is visible during the GRUB bootloader phase. However, as soon as the Linux Kernel initializes the ACPI and PCIe handoff, the enclosure is abruptly disconnected and shuts down.
Linux Kernel Troubleshooting Performed:
We spent over 4 hours troubleshooting the issue, testing more than 8 different combinations of Linux kernel boot parameters in GRUB (including pcie_aspm=off, usbcore.autosuspend=-1, iommu=pt, and intel_iommu=on). None of these software parameters resolved the disconnection, confirming that the motherboard’s firmware is dropping the PCIe tunneling link at a deeper level.
ACPI Errors Logged in Kernel Journal:
During boot, the Linux kernel reports several official ACPI compliance errors regarding this platform’s BIOS (T202), specifically:
ACPI BIOS Error (bug): Could not resolve symbol [_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND
ACPI Error: Aborting method _TZ.TZ00._TMP due to previous error
These errors indicate that the ACPI tables for Linux are misconfigured or missing entries, which directly correlates with the USB4 PCIe tunneling failure.
Why I cannot test on Windows:
My entire infrastructure is fully bare-metal Linux and macOS. I do not own Windows licenses or environments for this server deployment. Furthermore, I am aware that the newer BIOS T205 available on your site introduces severe networking regressions for many users (causing the dual 10Gbps Intel E610 ports to drop randomly). Since my 10G networking is currently rock-solid on BIOS T202, I cannot risk flashing T205 and compromising the core functionality of my server.
Conclusion & Request:
Since the hardware is proven to be perfect, this is a clear firmware/BIOS compatibility issue regarding how the Intel Core Ultra USB4 controller handles PCIe state handoff under Linux.
Could you please forward this detailed report to your BIOS Engineering Team? We would highly appreciate it if they could investigate this ACPI compliance bug and release a stable BIOS update that fixes USB4 tunneling on Linux without breaking the 10Gbps Ethernet stability.
Thank you very much for your time, professionalism, and dedication to making Beelink a great platform for power users.
Best regards

lukeH

sulaxna068debi Many thanks for your suggestion

lukeH

Beelink CS-Lynn Dear Beelink Support Team,
First of all, I would like to thank you for your support and congratulate you on the Beelink GTi15 Ultra (Intel Core Ultra 9 285H). It is an outstanding machine, and almost everything works flawlessly under Proxmox VE (Debian 13), including the excellent dual 10Gbps Ethernet ports.
However, I am contacting you regarding the 40Gbps USB4 port, which exhibits an ACPI/firmware-related issue when trying to use high-speed external enclosures under Linux.
Following your previous suggestion to verify if the port might be physically defective, I conducted rigorous troubleshooting sessions and performed a benchmark using a native USB-C external drive (Transcend ESD310S).
Here are the concrete findings that prove the hardware port is 100% functional, pointing instead to a BIOS / ACPI compliance bug:

Hardware Verification (10Gbps Mode Works Perfectly):
Under Linux, the Transcend ESD310S successfully and stably negotiates full 10000 Mbps (USB 3.2 Gen 2) via the UAS (USB Attached SCSI) driver. Direct sequential write benchmarks (dd with oflag=direct) yielded a rock-solid throughput of 840 MB/s. This mathematically proves that the Type-C port data lines, controller, and power delivery are working flawlessly at the hardware level.
The 40Gbps USB4 Bug:
The issue occurs only when connecting a true 40Gbps USB4/Thunderbolt enclosure (such as an ASMedia ASM2464PD based device). The drive receives power and is visible during the GRUB bootloader phase. However, as soon as the Linux Kernel initializes the ACPI and PCIe handoff, the enclosure is abruptly disconnected and shuts down.
Linux Kernel Troubleshooting Performed:
We spent over 4 hours troubleshooting the issue, testing more than 8 different combinations of Linux kernel boot parameters in GRUB (including pcie_aspm=off, usbcore.autosuspend=-1, iommu=pt, and intel_iommu=on). None of these software parameters resolved the disconnection, confirming that the motherboard’s firmware is dropping the PCIe tunneling link at a deeper level.
ACPI Errors Logged in Kernel Journal:
During boot, the Linux kernel reports several official ACPI compliance errors regarding this platform’s BIOS (T202), specifically: ACPI BIOS Error (bug): Could not resolve symbol [_SB.PC00.LPCB.ITE8.GETT], AE_NOT_FOUND ACPI Error: Aborting method TZ.TZ00.TMP due to previous error. These errors indicate that the ACPI tables for Linux are misconfigured or missing entries, which directly correlates with the USB4 PCIe tunneling failure.
Why I cannot test on Windows:
My entire infrastructure is fully bare-metal Linux and macOS. I do not own Windows licenses or environments for this server deployment. Furthermore, I am aware that the newer BIOS T205 available on your site introduces severe networking regressions for many users (causing the dual 10Gbps Intel E610 ports to drop randomly). Since my 10G networking is currently rock-solid on BIOS T202, I cannot risk flashing T205 and compromising the core functionality of my server.

Conclusion & Request:
Since the hardware is proven to be perfect, this is a clear firmware/BIOS compatibility issue regarding how the Intel Core Ultra USB4 controller handles PCIe state handoff under Linux.
Could you please forward this detailed report to your BIOS Engineering Team? We would highly appreciate it if they could investigate this ACPI compliance bug and release a stable BIOS update that fixes USB4 tunneling on Linux without breaking the 10Gbps Ethernet stability.
Thank you very much for your time, professionalism, and dedication to making Beelink a great platform for power users.
Best regards

lukeH

Beelink CS-Lynn [SOLVED] Full Solution & Workaround for 40Gbps USB4 Enclosures (ASM2464PD) on Linux / Proxmox VE (Beelink GTi15 Ultra)

UPDATE to my previous post:

I am happy to report that after extensive testing, we have found a 100% working, stable, and repeatable solution to run 40Gbps USB4 / Thunderbolt enclosures (specifically based on the ASMedia ASM2464PD chipset) natively at full speed on the Beelink GTi15 Ultra (Intel Core Ultra 9 285H) under Linux (Proxmox VE 9.2 / Debian 13).

If you are experiencing disconnections, dropped PCIe tunnels, or 60-second kernel boot delays with 40Gbps enclosures, here is the complete breakdown and fix.

Root Causes Identified

ASMedia Firmware Bug with Meteor Lake: Older enclosure firmwares (e.g., 25.04.17) fail the PCIe retimer handshake with Intel Core Ultra processors under Linux ACPI handoff.
ACPI PCIe Control: By default, Linux delegates PCIe port power management to the BIOS ACPI tables, which currently drop the USB4 tunnel upon kernel boot.
NVMe Admin Timeout: During early boot, timestamp synchronization on external USB4 NVMe drives can cause a 60-second kernel stall due to default admin timeouts.

The Step-by-Step Fix
Step 1: Update Enclosure Firmware
Update your ASMedia ASM2464PD enclosure firmware to version 25.07.17 (or newer) using a Windows PC before connecting it to Linux. This resolves the hardware retimer handshake bug.

Step 2: Configure Linux Kernel Boot Parameters (GRUB)
Edit /etc/default/grub and update GRUB_CMDLINE_LINUX_DEFAULT:
GRUB_CMDLINE_LINUX_DEFAULT=“quiet pcie_ports=native pcie_port_pm=off pcie_aspm=off nvme_core.default_ps_max_latency_us=0 nvme_core.admin_timeout=5 pci=noaer intel_iommu=on iommu=pt”

pcie_ports=native (CRITICAL): Forces the Linux kernel to take direct control of PCIe root ports instead of relying on broken ACPI handoffs.
nvme_core.admin_timeout=5 (CRITICAL): Reduces the NVMe admin command timeout from 60 seconds to 5 seconds, eliminating the long boot delay.
pcie_aspm=off & pcie_port_pm=off: Prevents aggressive PCIe power-saving states from dropping the tunnel 24/7.

Save and apply changes:
update-grub
reboot

Step 3: Add Thunderbolt Udev Authorization Rule
Create /etc/udev/rules.d/99-thunderbolt.rules with the following content to automatically authorize PCIe tunneling:

echo ‘ACTION==“add”, SUBSYSTEM==“thunderbolt”, ATTR{authorized}==“0”, ATTR{authorized}=“1”’ > /etc/udev/rules.d/99-thunderbolt.rules
udevadm control –reload-rules && udevadm trigger

Verified Results & Benchmarks

Boot Time: Kernel initialization time dropped from 1 min 4 sec down to 3.09 seconds across both cold and warm reboots.
Stability: Fully stable across power cycles (S5 state) and continuous 24/7 operation.
Real Direct I/O Benchmarks (dd with oflag=direct / iflag=direct):
Direct Sequential Write: 2,200 MB/s (Saturating the Samsung 970 Pro hardware write limit)
Direct Sequential Read: 3,000–3,200 MB/s (Saturating the full physical bandwidth of the 40Gbps USB4 tunnel)

Note to Beelink Engineers: While this kernel-side configuration completely solves the issue for Linux users, we still recommend incorporating proper ACPI PCIe tunneling tables in future BIOS releases so that USB4 works out-of-the-box without manual GRUB tweaks.

Hope this helps other Linux power users on this platform!

Beelink CS-Lynn

lukeH
Your detailed explanation of the troubleshooting steps is amazing! Thank you for providing such a thorough response that serves as a helpful reference for other customers on the forum facing the same issue. Thank you for your suggestions and for your contributions to the Beelink community.