Re: [REGRESSION] Thunderbolt Host Reset Change Causes eGPU Disconnection from 6.8.7=>6.8.8

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Sun, Aug 30, 2026 at 11:33:31PM +0200, František Tichý wrote:
> Hi all,
> 
> I've run into this issue on 7.0.10, 7.1.6, 7.1.8 and 7.1.9 (specifically
> Linux 7.1.9-arch1-2), as well as LTS kernel 6.18.45.
> 
> to Mario's questions (thank you for them; they were captured on the
> 7.1.9 kernel):
> 
> > Can we please get some kernel logs for these two cases on the command
> line?
> >
> > thunderbolt.dyndbg=+p
> 
> Here you are, the system does not load the graphical interface:
> https://gist.github.com/Poirot12345T/be6b7849e039687e248b8c302615d9f3
> 
> > thunderbolt.dyndbg=+p thunderbolt.host_reset=false
> 
> In this case, graphical interface loaded successfully:
> https://gist.github.com/Poirot12345T/c63a1a3b2b6609b30a1182e7681fbec1
> 
> > Also what is the value for:
> >
> > $ cat /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection
> 
> That returns as "1" on my system.
> 
> I've also done some digging myself, here's what I found out:
> 
> (note: I will use host_reset=0 in this post, even though the thread used
> host_reset=false. These two values are functionally identical.)

Yes correct.

> Originally tracked down in amdgpu bug tracker
> (https://gitlab.freedesktop.org/drm/amd/-/work_items/5632) and based on
> the suggestion to use thunderbolt.host_reset=false mentioned in this
> thread, I traced back the issue to commit 59a54c5f3dbd (authored by
> Sanath S, CC'd) which touched drivers/thunderbolt/tb.c (Thunderbolt/USB
> subsystem, added Mika Westerberg as a maintainer and CC'd linux-usb
> mailing list), more specifically function tb_start() and this code block:
> 
>     /*
>      * Boot firmware might have created tunnels of its own. Since we
>      * cannot be sure they are usable for us, tear them down and
>      * reset the ports to handle it as new hotplug for USB4 v1
>      * routers (for USB4 v2 and beyond we already do host reset).
>      */
>     if (reset && tb_switch_is_usb4(tb->root_switch)) {
>         discover = false;
>         if (usb4_switch_version(tb->root_switch) == 1)
>             tb_switch_reset(tb->root_switch);
>     }
> 
> This block should be located between lines 3060 and 3070 of the above
> mentioned file as of the time I am writing this post.

Does is work if you boot with the device connected (and host_reset=0) and
then once the system is up, unplug the eGPU wait a little and plug it back?
That's essentially the same thing as what host_reset is doing and is pretty
much the nature of buses like USB4 (e.g the user can unplug the device at
any given time and plug it back later expecting it to work).

> I was able to reproduce this issue using AMD RX 7600 (journalctl dump
> link:
> https://gist.github.com/Poirot12345T/909f3d071f87655d875445e536da74d3).
> I have also tried NVIDIA RTX 5060 with the nvidia-open driver which did
> not trigger this behavior in the default setting. (journalctl:
> https://gist.github.com/Poirot12345T/4deeae10508e3971521aca9e612b5737)

It depends on the GPU driver. Some of them are prepared for PCIe
hot-removal, some are not yet. With the rise of eGPUs I would expect that
we are seeing more and more support for this though.

The ones you shared above looks like amdgpu driver and I don't see any
issues in the dmesg.