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

[Mario Limonciello <mario.limonciello@amd.com>]

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@amd.com/

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.