| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAFv23Q=bLCif750y8eDEP4J+KwVy8CknZawYOGZWWrBSiE8FNA@mail.gmail.com>
Date: Wed, 17 Dec 2025 11:06:52 +0800
From: AceLan Kao <acelan.kao@...onical.com>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>,
Andreas Noever <andreas.noever@...il.com>, Mika Westerberg <westeri@...nel.org>,
Yehezkel Bernat <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, Sanath.S@....com,
"Lin, Wayne" <Wayne.Lin@....com>
Subject: Re: [PATCH] [RFC] thunderbolt: Add delay for Dell U2725QE link width
Mario Limonciello <mario.limonciello@....com> 於 2025年12月12日週五 下午10:40寫道：
>
> 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.
Sorry, it looks like I got some troubles with my MTA, some emails are
not sent out correctly.
I've rebuilt the kernel without CONFIG_USB4_DEBUGFS_MARGINING, and
here is the log
There is a tbt storage daisy-chained after the tbt monitor, it's
easier to reproduce this issue.
https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.2.out
And this one is only the tbt monitor plugged.
https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.3.out
>
> If this does end up being the reason - maybe we should make this really
> noisy in logs and/or taint the kernel.
Powered by blists - more mailing lists