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

[Mario Limonciello]

On 8/30/26 23:52, Mika Westerberg wrote:
> 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.

I don't doubt there to be gotchas and corner cases with hotplugging an eGPU.

More testing is going to find cases of bad assumptions on mutexes, ref 
counting issues etc.

I do want to note that for amdgpu we're disabling runtime PM for eGPUs 
starting in 7.4.

https://lore.kernel.org/amd-gfx/20260812080841.2936007-1-kevinyang.wang@xxxxxxx/

You can experiment with 'amdgpu.runpm=0' on kernel command line.  If 
that helps an issue, then what's coming in 7.4 will help as well.