Hi Rick, On Wed, Oct 30, 2024 at 08:11:30AM +0100, Rick wrote: > Hi Mika, > > Thank you for your email. > > On 28-10-2024 09:18, Mika Westerberg wrote: > > > > I still see similar issue even with the v6.9 kernel. The link goes up an > > down unexpectly. > > > > I wonder if you could try to take traces of the control channel traffic? > > I suggest to use v6.11 kernel because it should have all the tracing > > bits added then install tbtools [1] and follow the steps here: > > > > https://github.com/intel/tbtools?tab=readme-ov-file#tracing > > > > Then provide both full dmesg and the trace output. That hopefully shows > > if some of the access we are doing in the Linux side is causing the link > > to to drop. Let me know if you need more detailed instructions. > > > > Also please drop the "thunderbolt.host_reset=0" from the command line as > > that did not help, so it is not needed. > > Dropped thank you. > > > > > [1] https://github.com/intel/tbtools > > tbtrace on 6.11.5: > https://gist.github.com/ricklahaye/69776e9c39fd30a80e2adb6156bdb42d > dmesg on 6.11.5: > https://gist.github.com/ricklahaye/8588450725695a0bd45799d3d66c7aff Thanks! I suspect there is something we do when we read the sideband that makes the device router to "timeout" and retry the link establishment. There is also the failure when USB 3.x tunnel is created but we can look that after we figure out the connection issue. Looking at the trace we are still polling for retimers when we see the unplug: [ 48.684078] tb_tx Read Request Domain 0 Route 0 Adapter 3 / Lane 0x00/---- 0x00000000 0b00000000 00000000 00000000 00000000 .... Route String High 0x01/---- 0x00000000 0b00000000 00000000 00000000 00000000 .... Route String Low 0x02/---- 0x02182091 0b00000010 00011000 00100000 10010001 .... [00:12] 0x91 Address [13:18] 0x1 Read Size [19:24] 0x3 Adapter Num [25:26] 0x1 Configuration Space (CS) → Adapter Configuration Space [27:28] 0x0 Sequence Number (SN) [ 48.684339] tb_rx Read Response 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/---- 0x02182091 0b00000010 00011000 00100000 10010001 .... [00:12] 0x91 Address [13:18] 0x1 Read Size [19:24] 0x3 Adapter Num [25:26] 0x1 Configuration Space (CS) → Adapter Configuration Space [27:28] 0x0 Sequence Number (SN) 0x03/0091 0x81320408 0b10000001 00110010 00000100 00001000 .2.. PORT_CS_1 [00:07] 0x8 Address [08:15] 0x4 Length [16:18] 0x2 Target [20:23] 0x3 Re-timer Index [24:24] 0x1 WnR [25:25] 0x0 No Response (NR) [26:26] 0x0 Result Code (RC) [31:31] 0x1 Pending (PND) [ 48.691410] 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 [ 48.691414] thunderbolt 0000:00:0d.2: acking hot unplug event on 0:3 Taking this into account and also the fact that your previous email you say that v6.9 works and v6.10 does not, I wonder if you could first try just to revert: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") and see if that helps with the connection issue? If it does then can you take full dmesg and the trace again and with me so I can look at the USB tunnel issue too?
