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

[Mario Limonciello]

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@xxxxxxxxxxxxx/
> > >
> > > 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.