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

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

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.