Re: [PATCH] [RFC] thunderbolt: Add delay for Dell U2725QE link width

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

On 12/12/25 6:39 AM, Mika Westerberg wrote:
> Hi,
> 
> On Fri, Dec 12, 2025 at 12:10:24PM +0800, Chia-Lin Kao (AceLan) wrote:
>> Hi Mika,
>>
>> On Wed, Dec 10, 2025 at 03:42:21PM -0600, Mario Limonciello wrote:
>>> +Wayne
>>>
>>> Here is the full thread since you're being added in late.
>>>
>>> https://lore.kernel.org/linux-usb/20251209054141.1975982-1-acelan.kao@canonical.com/
>>>
>>> On 12/10/25 1:41 AM, Mika Westerberg wrote:
>>>> Hi,
>>>>
>>>> On Wed, Dec 10, 2025 at 11:15:25AM +0800, Chia-Lin Kao (AceLan) wrote:
>>>>>> We should understand the issue better. This is Intel Goshen Ridge based
>>>>>> monitor which I'm pretty sure does not require additional quirks, at least
>>>>>> I have not heard any issues like this. I suspect this is combination of the
>>>>>> AMD and Intel hardware that is causing the issue.
>>>>> Actually, we encountered the same issue on Intel machine, too.
>>>>> Here is the log captured by my ex-colleague, and at that time he used
>>>>> 6.16-rc4 drmtip kernel and should have reported this issue somewhere.
>>>>> https://paste.ubuntu.com/p/bJkBTdYMp6/
>>>>>
>>>>> The log combines with drm debug log, and becomes too large to be
>>>>> pasted on the pastebin, so I removed some unrelated lines between 44s
>>>>> ~ 335s.
>>>>
>>>> Okay I see similar unplug there:
>>>>
>>>> [  337.429646] [374] thunderbolt:tb_handle_dp_bandwidth_request:2752: thunderbolt 0000:00:0d.2: 0:5: handling bandwidth allocation request, retry 0
>>>> ...
>>>> [  337.430291] [165] thunderbolt:tb_cfg_ack_plug:842: thunderbolt 0000:00:0d.2: acking hot unplug event on 0:1
>>>>
>>>> We had an issue with MST monitors but that resulted unplug of the DP OUT
>>>> not link going down. That was fixed with:
>>>>
>>>>     9cb15478916e ("drm/i915/dp_mst: Work around Thunderbolt sink disconnect after SINK_COUNT_ESI read")
>>>>
>>>> If you have Intel hardware still there it would be good if you could try
>>>> and provide trace from that as well.
>> I tried the latest mainline kernel, d358e5254674, which should include the commit you
>> mentioned, but no luck.
>>
>> I put all the logs here for better reference
>> https://people.canonical.com/~acelan/bugs/tbt_call_trace/
>>
>> Here is how I get the log
>> ```
>> $ cat debug
>> #!/bin/sh
>>
>> . ~/.cargo/env
>> sudo ~/.cargo/bin/tbtrace enable
>> sleep 10 # plug in the monitor
>> sudo ~/.cargo/bin/tbtrace disable
>> sudo ~/.cargo/bin/tbtrace dump -vv > trace.out
>> sudo dmesg > dmesg.out
>> ./tbtools/scripts/merge-logs.py dmesg.out trace.out > merged.out
>> ```
>>
>> And here is the log
>> https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.out
> 
> Thanks!
> 
> It shows that right before the unplug the driver is still enumerating
> retimers:
> 
> [   39.812733] tb_tx Read Request Domain 0 Route 3 Adapter 1 / Lane
>                 0x00/---- 0x00000000 0b00000000 00000000 00000000 00000000 .... Route String High
>                 0x01/---- 0x00000003 0b00000000 00000000 00000000 00000011 .... Route String Low
>                 0x02/---- 0x02082091 0b00000010 00001000 00100000 10010001 ....
>                   [00:12]       0x91 Address
>                   [13:18]        0x1 Read Size
>                   [19:24]        0x1 Adapter Num
>                   [25:26]        0x1 Configuration Space (CS) → Adapter Configuration Space
>                   [27:28]        0x0 Sequence Number (SN)
> [   39.813005] tb_rx Read Response Domain 0 Route 3 Adapter 1 / Lane
>                 0x00/---- 0x80000000 0b10000000 00000000 00000000 00000000 .... Route String High
>                 0x01/---- 0x00000003 0b00000000 00000000 00000000 00000011 .... Route String Low
>                 0x02/---- 0x02082091 0b00000010 00001000 00100000 10010001 ....
>                   [00:12]       0x91 Address
>                   [13:18]        0x1 Read Size
>                   [19:24]        0x1 Adapter Num
>                   [25:26]        0x1 Configuration Space (CS) → Adapter Configuration Space
>                   [27:28]        0x0 Sequence Number (SN)
>                 0x03/0091 0x81620408 0b10000001 01100010 00000100 00001000 .b.. PORT_CS_1
>                   [00:07]        0x8 Address
>                   [08:15]        0x4 Length
>                   [16:18]        0x2 Target
>                   [20:23]        0x6 Re-timer Index
>                   [24:24]        0x1 WnR
>                   [25:25]        0x0 No Response (NR)
>                   [26:26]        0x0 Result Code (RC)
>                   [31:31]        0x1 Pending (PND)
> [   39.814180] tb_tx Read Request Domain 0 Route 3 Adapter 1 / Lane
>                 0x00/---- 0x00000000 0b00000000 00000000 00000000 00000000 .... Route String High
>                 0x01/---- 0x00000003 0b00000000 00000000 00000000 00000011 .... Route String Low
>                 0x02/---- 0x02082091 0b00000010 00001000 00100000 10010001 ....
>                   [00:12]       0x91 Address
>                   [13:18]        0x1 Read Size
>                   [19:24]        0x1 Adapter Num
>                   [25:26]        0x1 Configuration Space (CS) → Adapter Configuration Space
>                   [27:28]        0x0 Sequence Number (SN)
> [   39.815193] tb_event Hot Plug Event Packet Domain 0 Route 0 Adapter 3 / Lane
>                 0x00/---- 0x80000000 0b10000000 00000000 00000000 00000000 .... Route String High
>                 0x01/---- 0x00000000 0b00000000 00000000 00000000 00000000 .... Route String Low
>                 0x02/---- 0x80000003 0b10000000 00000000 00000000 00000011 ....
>                   [00:05]        0x3 Adapter Num
>                   [31:31]        0x1 UPG
> [   39.815196] [2821] thunderbolt 0000:00:0d.2: acking hot unplug event on 0:3
> 
> By default it does not access retimers beyond the Type-C connector. I
> wonder if you have CONFIG_USB4_DEBUGFS_MARGINING set in your kernel
> .config? And if yes can you disable that and try again.

If this does end up being the reason - maybe we should make this really 
noisy in logs and/or taint the kernel.