Received-SPF: pass (google.com: domain of linux-kernel+bounces-184496-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 21 May 2024 07:59:40 +0300
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Benjamin =?utf-8?Q?B=C3=B6hmke?= <benjamin@boehmke.net>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
	Christian Heusel <christian@heusel.eu>,
	Linux regressions mailing list <regressions@lists.linux.dev>,
	Gia <giacomo.gio@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"kernel@micha.zone" <kernel@micha.zone>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"S, Sanath" <Sanath.S@amd.com>
Subject: Re: [REGRESSION][BISECTED] "xHCI host controller not responding,
 assume dead" on stable kernel > 6.8.7
Message-ID: <20240521045940.GJ1421138@black.fi.intel.com>
References: <CAHe5sWavQcUTg2zTYaryRsMywSBgBgETG=R1jRexg4qDqwCfdw@mail.gmail.com>
 <38de0776-3adf-4223-b8e0-cedb5a5ebf4d@leemhuis.info>
 <lqdpk7lopqq4jn22mycxgg6ps4yfs7hcca33tqb2oy6jxc2y7p@rhjjbzs6wigu>
 <611f8200-8e0e-40e4-aff4-cc2c55dc6354@amd.com>
 <61-664b6880-3-6826fc80@79948770>
 <20240520162100.GI1421138@black.fi.intel.com>
 <5d-664b8000-d-70f82e80@161590144>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5d-664b8000-d-70f82e80@161590144>

Hi,

On Mon, May 20, 2024 at 06:53:18PM +0200, Benjamin Böhmke wrote:
> > All the USB devices seem to work fine (assuming I read this right).
> 
> To keep the log small I unplugged all USB devices from the dock.
> But even if connected I don't have issues with them.

Okay that's good to know.

Yeah, in the dmesg it might seem odd that the xHCI is "gone" for a while
as we do USB4 topology reset but it comes back after the tunnels get
re-created.

> > There is the DP tunneling limitation but other than that how the dock
> > does not work? At least reading this log everything else seems to be
> > fine except the second monitor?
> 
> Exactly only the second monitor is/was not working.

Got it.

> > Now it is interesting why the link is only 20G and not 40G. I do have
> > this same device and it gets the link up as 40G just fine:
> > 
> > [   17.867868] thunderbolt 0000:00:0d.2: 1: current link speed 20.0 Gb/s
> > [   17.867869] thunderbolt 0000:00:0d.2: 1: current link width symmetric, single lane
> > [   17.868437] thunderbolt 0000:00:0d.2: 0:1: total credits changed 120 -> 60
> > [   17.868625] thunderbolt 0000:00:0d.2: 0:2: total credits changed 0 -> 60
> > [   17.872472] thunderbolt 0000:00:0d.2: 1: TMU: current mode: bi-directional, HiFi
> > [   17.872608] thunderbolt 0-1: new device found, vendor=0x3d device=0x11
> > [   17.879102] thunderbolt 0-1: CalDigit, Inc. TS3 Plus
> > 
> 
> My dock is a little different model (see https://www.caldigit.com/usb-c-pro-dock/)
> I don't have a CalDigit TS3 Plus.

Indeed, my mistake.

> > Do you use a Thunderbolt cable or some regular type-C one? There is the
> > lightning symbol on the connector when it is Thunderbolt one.
> 
> The dock was connected with a Thunderbolt cable, that I used for a
> couple of years without any issues. Based on the hint I replaced the
> cable and the issue is now gone for me.
> 
> I still don't understand why this happened as it was working great for
> years and is still working with kernels 6.8.7 or older. But
> nevertheless sorry if I wasted time of anyone because of broken
> hardware.

I think the BIOS CM creates the "first" tunnel using reduced
capabilities already so this makes the "second" tunnel fit there in the
18G link. Now that we do the reset the "first" tunnel is re-created with
max capabilities and that makes the "second" not to fit there anymore.

But now you get the full 40G link :)