[Bug 221319] New: Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot

[bugzilla-daemon@kernel.org]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: foss@morgwai.pl
        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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.