New: Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=221319
Bug ID: 221319
Summary: Certain operations via PCIe tunneling between an AMD
USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 309813
--> https://bugzilla.kernel.org/attachment.cgi?id=309813&action=edit
dmesg log when using Nouveau driver
I have an AMD Strix laptop (TUXEDO IBP-14 gen10, HX370 APU) and an RTX 3090 that I’ve been successfully connecting using various eGPU adapters:
- ADT-Link UT4G (USB4v1, ASM2464PDX),
- Minisforum DEG1 (OCuLink 4i),
- even daisy-chaining two 3090s via EXP-GDC TH3P4G3 (TB3, JHL7440) + UT4G
...and it has all been working perfectly stable on my Debian-13 system across several kernel versions (6.16.1 - 7.0~rc6) using both Nouveau and NV proprietary drivers.
Recently I’ve purchased a new TB5 adapter: Minisforum DEG2: it is quite new, but a few reviews it received from Windows users praised it for perfect stability and flawless work.
However when I connected my 3090 via my new DEG2 to my laptop, it abruptly rebooted about 0.5-1 second after the driver was loaded. I’ve tried several driver versions across different distros (live Fedora-43+Nouveau, live POP_OS-24.04+v580, Debian-13+{Nouveau,v580,v590,v595} with kernels 6.18.x,6.19x distro-provided and self-compiled 7.0~rc6), but the result was always the same.
I also subjected myself to some Windows-11 usage and confirmed that my DEG2 works perfectly stable there with NV's Studio Driver v591.74.
Given all above, it seems that the problem is related to TB5 handling by the kernel.
After some hair-pulling and extensive testing, I’ve managed to notice, that the operation that causes the reboots is somehow related to GSP firmware: I’ve verified that the following configurations allow the eGPU to work somewhat stable:
- Nouveau driver without firmware-nvidia-graphics package (containing GSP
v570.144)
- NV's proprietary flavor driver (package cuda-drivers from their repo)
v580, v590 and v595 with options nvidia NVreg_EnableGpuFirmware=0 (NV's "open" flavor cannot function without GSP firmware and ignore this option)
Also redirecting the 3090 to a VM via VFIO and loading the firmware inside a VM causes the whole laptop to reboot (with either Nouveau or v580 or v590 installed in the VM).
Redirecting the 3090 to a VM with v595 installed, causes a reboot of the laptop even without loading the firmware (ie even with having options nvidia NVreg_EnableGpuFirmware=0 inside the VM).
Note: there were also numerous reports on egpu.io forum of vast instability from Intel host + TB5 adapter + Linux users to the point of being completely unusable, though without reboots. A few of such users that were using Nvidia GPUs reported that avoid GSP firmware also mitigated the problem.
Attached are dmesg logs from Debian-13 with self compiled kernel 7.0~rc6 under the following scenarios:
dmesg-deg2-x4sp4nal-debian13-linux7.0rc6-nouveau.log:
1. initially package firmware-nvidia-graphics containing the GSP firmware is not installed.
2. eGPU is connected and is properly detected by Nouveau, nothing bad happens.
3. Nouveau is unloaded and eGPU is disconnected.
4. firmware-nvidia-graphics is installed.
5. eGPU is connected and reboot occurs about 0.5-1 second after loading the firmware.
dmesg-deg2-x4sp4nal-debian13-linux7.0rc6-nv595: (to be posted in the next comment)
1. initially cuda-drivers v595 is installed and /etc/modprobe.d/nvidia-nogsp.conf file contains options nvidia NVreg_EnableGpuFirmware=0.
2. eGPU is connected and is properly detected by the NV driver, nothing bad happens.
3. all NV modules are unloaded and eGPU is disconnected.
4. NVreg_EnableGpuFirmware is changed to 1.
5. eGPU is connected and reboot occurs about 0.5-1 second after loading the driver.
Related links:
Corresponding egpu.io thread:
https://egpu.io/forums/wip-builds/wip-2025-14-tuxedo-infinitybook-pro-14-gen10-890m-rai312chx-rtx-3090-64gbps-usb4v1-minisforum-deg2-linux-debian-trixie-loading-nvidia-firmware-reboots-the-machine/
Windows build on egpu.io:
https://egpu.io/forums/builds/2025-14-tuxedo-infinitybook-pro-14-gen10-890m-rai312chx-rtx-3090-64gbps-usb4v1tb5-minisforum-deg2-win11-25h2-daisy-chained-rtx-3090-via-ut4g/
Nvidia Linux forum posting:
https://forums.developer.nvidia.com/t/loading-gsp-firmware-from-an-amd-strix-laptop-to-a-tb5-3090-egpu-causes-instant-reboot/360903
Sometimes a split second before a reboot, there are some error messages from amdgpu, so I also posted to their bug tracker, but it seems amdgpu is rather a victim, not a cause:
https://gitlab.freedesktop.org/drm/amd/-/work_items/4981
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #1 from Morgwai Kotarbinski ([email protected]) --- Created attachment 309814
--> https://bugzilla.kernel.org/attachment.cgi?id=309814&action=edit
dmesg log when using NV driver v595
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #2 from Mario Limonciello (AMD) ([email protected]) --- Can you check the log from the kernel on the boot AFTER this happened? There will be a log event indicating the last reboot reason.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #3 from Morgwai Kotarbinski ([email protected]) --- Created attachment 309828
--> https://bugzilla.kernel.org/attachment.cgi?id=309828&action=edit
dmesg log from the boot after a deg2-induced reboot
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #4 from Morgwai Kotarbinski ([email protected]) --- Created attachment 309829
--> https://bugzilla.kernel.org/attachment.cgi?id=309829&action=edit
systemd journal from a deg2-induced reboot and the boot after
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #5 from Morgwai Kotarbinski ([email protected]) --- @Mario, thanks for your reply! :)
I've had a look at the logs on the next boot, but cannot find anything relevant. I've attached the dmesg output from the boot after and the systemd journal from a reboot and the boot after: perhaps you will be able to find this info there.
Otherwise please advise me if I need to add some kernel boot params or configure some other log gathering or apply some patches to my kernel to collect some more useful data: to be honest I don't know how to proceed further from here on my own.
Thanks :)
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #6 from Mario Limonciello (AMD) ([email protected]) --- Here's the message that I was looking for:
Quoted 2 lines
[ 1.657766] x86/amd: Previous system reset reason [0x08000800]: anuncorrected error caused a data fabric sync flood event
I suspect that there are some PCIe errors occurring either internal to the SoC or (more likely) between the SoC and your new device. These are causing a flood of problems, and then the BIOS eventually triggers an internal watchdog that reboots the system.
Try adding this to your kernel command line and we'll see if there is anything new from the PCI core about the issue:
Quoted 1 line
pcie_ports=native pcie_ecrc=on
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221319
Mario Limonciello (AMD) ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|USB |PCI
Assignee|[email protected] |[email protected]
|nel.org |l.orgSignature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.