From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A56E4302753 for ; Thu, 28 May 2026 03:44:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.188.122 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779939843; cv=none; b=BUgk+QZx4HRcGSSpy+yPK3Phg1n9JdC6da/81ez2GSqrV/ku6UnHDxUazn0m25HoxlDfdTE/M0NeWUamYR1uJwNbj3kBkIM7MlmPbm9l+O3nd0USdcbRFBqwYodT8pGvn/b9rnB+FAyyF4F//01jODtP3EfG/XE4nxLQN0j6B6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779939843; c=relaxed/simple; bh=NsTIyMeXJn8h2xIDwOz+QGYKegXoQSBAwdhImJ+Ri0Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O267yEQNX2owpL/EJPUjUgRc8iScMlgsiEsqgFnkP/SxlvdZuiYC90t6klYyWrecj9DS5QW2Im5h5to5uH+Ir79qJSEkGRCDYJKHBQ43jM0YhzlhQLCok/t7U/tjrhKsKCfHBR99fDFfBZsEhLumU99Z8gGzqFOOpNrwKqR+hzM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com; spf=pass smtp.mailfrom=canonical.com; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b=po4ZdZ6P; arc=none smtp.client-ip=185.125.188.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=canonical.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b="po4ZdZ6P" Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id D623A3F29D for ; Thu, 28 May 2026 03:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20251003; t=1779939838; bh=QVdeuz+QoVJvULpmGgf66uGnzncOj1822+cFm5CY+DQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=po4ZdZ6PGfCcFKltx2nL9fF0lLHgxeFWI654quInOV4En9YxkzZV8z24CxhVtXQ9P fxLnUal5UG9LzVIDYcYsffFgMNe0iLE+UAl6Q/0EbOKnPJnO60IFCeLeef4hB98XC2 spOdDcowymVMes+PdZL2h4dt5zBHiVCIA7jp7He6fQSmsDxpLD/4T87D7troGMUaI+ n3VlsvbJQ50PEpoQM8pBLaQHBa1eM4xqu0CzrjoE3+hhvpirRriKkM2jhP798YhRyh iqUrkv6BfgSUcjqB5aTHmOgiTauueZQZpKayP+PO0UZP65LGWA8U+SA1HxrO9LJhry oiyiNPO6z/897peud3x9TvyD4ju4lAO9u6TNQHVvDE586aeddxB2ykglcRDCf1BEOc uXXIvtCga1dmDp33JhtZxDkl/5wG54ezBGkyHuuLC5l1TrdjdoKd5rqOX9wTKEbXp5 J2UCvW6lGLjI0D2WnIYREbCPV2jMHTFh5V+osgo7evVoP1hjoSZeAUQrBdF3gAQbtY MjNLu+VJpa0ySg0jM54oSsknp94hUViUIHwYuZf67qThYbrTBN91nK24GVOOiM2577 1cKveZkLe3I2yMq/qSrtKP/3ZYF1HMt3+5AavlRlcK4//9jXtTlbkapQQhHZkUHesm wGpc/H4FsiImiHj0DoWjVCTw= Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-7dbb5e586c1so21164297b3.3 for ; Wed, 27 May 2026 20:43:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779939838; x=1780544638; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QVdeuz+QoVJvULpmGgf66uGnzncOj1822+cFm5CY+DQ=; b=hdYYztL7AgE6qCeXODxz/y8LEoiF1uo0Z8ePzYm9Lo85bMUZdfZ5js3flGRySR7Z1a SVtWZvk50JHUgDgPqX+yMa9JlV4Czlalt72+6PYgIX7CCHsh0vnVHvoFYs2TkBkmQ10s 4/oaAWumBos+alJ1cs+YBJIvJZAyNwG5MkAVO/raawyu8eSOElRBc3Cv0rETXnvn/T7+ 960a7N9pxCO6tHupro1cTRUe9SPRJP97rji7i8Q+zAlJyhrnol25dwEIsxe7SyodsQEa 6KuUlaYO3WA+2e7i5jN1O70A3s7ps0EdFStPF7+neWECpGuqffIGNIk9pZdQIQpXb97S TPZA== X-Forwarded-Encrypted: i=1; AFNElJ9PwWR4DtQZFeewuXgAsCY4LhMLkVxt9Bd0odqtvo4GfdlSi95KFAQEHHkeNx6AQAwBIgCABE8Z8G2M+S4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy30vuvt91beM2teSPXgoN/rhHOlc37g84Oaz4vF7bdvpqn74Rl Onhi/ZjCHuN1OyuFsrm+hDTSC7mEFiNQhqb56Sii7gl0CbKMeOxfkmAIMPBEeqWraUv19QKMPZB 7EzH/HwUdg73q60f/xAs39bc/rjVnuTws5/6n5U942jb7TVUSm6rpFdIcg13L3VRrQ/8pnnmJCQ Venir7vaz+LY43q7oA X-Gm-Gg: Acq92OHrltqaqQJInp57Stc9v1F1F11f+i5ZXs4rg2VYyyIqQ9GjSRZ+ojKf8wVlKOh igc4IZdHp6eG5s8tDWQ4u5/dQ0xi+jn2C3rpf7TZA0bFLp50oKMy648rM4aRtPNE/AKGdUmDrj9 j9i75AbKT9GdnbRdGLx72FQxnM5InDGwKJ15JXNLC9ihbhaO9kFgilqLORAZP6ypDfRDu34Y7Tg A1uHFhFZ5+cFQWK0cGjtwPQknNHIRA5d7HesILNZR67diHnchGHAI2so4R7P5obCOcatgKdsDZr VmM1HtsFqKbetfMq1/0i8E50pAdLjQMpLcRp3/TFREAZYZG43ldCAaURUJOXepKAWN+crnqrO9G 7JQ8LBwZveIj35ztWTCeTkN7GxzAb3Y6nFy+xnma9lTNsNA3iimNfmK3RsReghOjoMFvIs1bERo +7TDe/UgUV3q2w X-Received: by 2002:a05:690c:6b04:b0:7d0:3bbc:c81 with SMTP id 00721157ae682-7d335fbcccamr275565697b3.13.1779939837824; Wed, 27 May 2026 20:43:57 -0700 (PDT) X-Received: by 2002:a05:690c:6b04:b0:7d0:3bbc:c81 with SMTP id 00721157ae682-7d335fbcccamr275565467b3.13.1779939837459; Wed, 27 May 2026 20:43:57 -0700 (PDT) Received: from acelan-Precision-5480 (211-75-139-220.hinet-ip.hinet.net. [211.75.139.220]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7dc3c8ec6dfsm7459867b3.22.2026.05.27.20.43.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 20:43:56 -0700 (PDT) Date: Thu, 28 May 2026 11:43:47 +0800 From: "Chia-Lin Kao (AceLan)" To: Mika Westerberg Cc: Mika Westerberg , Andreas Noever , Yehezkel Bernat , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/1] thunderbolt: Fix blank external display after HRR on USB4 v2 Message-ID: Mail-Followup-To: "Chia-Lin Kao (AceLan)" , Mika Westerberg , Mika Westerberg , Andreas Noever , Yehezkel Bernat , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260430073145.331419-1-acelan.kao@canonical.com> <20260430100311.GE557136@black.igk.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260430100311.GE557136@black.igk.intel.com> Hi Mika, Sorry for the late reply — I was away for two weeks in early May. On Thu, Apr 30, 2026 at 12:03:11PM +0200, Mika Westerberg wrote: > Hi, > > On Thu, Apr 30, 2026 at 03:31:42PM +0800, Chia-Lin Kao (AceLan) wrote: > > Hi, > > > > On Dell XPS 14 (Panther Lake) with a WD22TB4 Thunderbolt dock and BenQ > > PD2725U external display, the display goes permanently blank on ~50% of > > boots. The only way to recover is a full reboot — re-plugging the > > monitor or dock does not help. > > > > The root cause is a race between the USB4 v2 Host Router Reset (HRR) > > and the graphics driver initialization: > > > > 1. nhi_probe() performs HRR at ~t=1s, destroying BIOS-established > > DP tunnels. > > 2. The Thunderbolt driver re-discovers the dock via hotplug at ~t=4s > > and attempts to re-create the DP tunnel. > > 3. DPRX negotiation fails because the graphics driver (xe) is not yet > > ready — the 12-second timeout expires at ~t=18s. > > 4. tb_dp_tunnel_active() permanently removes the DP IN adapter from > > available resources on the first failure, so the display never > > recovers. > > > > The fix adds a retry mechanism: on DPRX negotiation failure, the driver > > retries up to 3 times with a 5-second delay, giving the graphics driver > > time to come up. > > > > Tested with 13 boot cycles on the affected machine: > > - 6 boots hit the HRR + DPRX race: all recovered via retry, display > > came online after 3 retry attempts (~58s). > > - 5 clean boots (no HRR): DP tunnel established immediately. > > - 2 boots with HRR where DPRX succeeded on first try. > > - 0 teardowns: the retry mechanism was never exhausted. > > > > Full dmesg log - https://people.canonical.com/~acelan/bugs/dp-retry-on-hrr/ > > I'm looking at that but the first thing that stands out is this: > > [ 1.051684] thunderbolt: loading out-of-tree module taints kernel. > > Which tells me that this has some potential modifications outside of the > mainline. > > Second thing is that it's missing "thunderbolt.dyndbg=+p" that could show > what is going on there. I suggest adding that pretty much always. > > Yes, this can happen and the 12 s idea was that it accounts for the > possible time that it takes to boot up (as well as the polling the i915 > does if it is runtime suspended). I would say that whatever is delaying the > boot time should be investigated first because that's not really good user > experience. > > Aside from that if you add "thunderbolt.dprx_timeout=-1" does it work? If > really needed we can increase that a bit but I'm not too enthustiatic > adding code for retrying this because we do have this timeout that we can > adjust as needed (we can make the default higher). Thank you for reviewing and for the helpful suggestions. I have an update on this issue: we've since discovered that a BIOS update (from 1.2.1/1.3.1 to 1.5.1) on this Dell XPS 14 (Panther Lake) appears to have resolved the blank display problem. Looking at what changed: with the old BIOS, the firmware pre-established PCIe tunnels through the dock during early boot — the dock's xHCI (07:00.0) and the OWC NVMe (18:00.0) were already enumerated by BIOS before the kernel started. When nhi_probe() performed HRR at ~t=1s, it destroyed those BIOS-established tunnels, killing xHCI mid-probe ("HC died; cleaning up") and causing the NVMe probe to fail with -EIO. The subsequent DP tunnel re-creation then hit the DPRX timeout because the graphics driver wasn't ready yet. With BIOS 1.5.1, the firmware no longer pre-establishes PCIe tunnels to dock devices — the TBT root port (00:07.0) doesn't even have IO port space allocated anymore. This means HRR has nothing to destroy, and the Thunderbolt driver handles all tunnel setup from scratch. We ran 30 reboot cycles with the full device set (WD22TB4 dock, BenQ monitor, OWC Envoy Express storage) and saw 0% blank display rate. So it seems the root cause was the BIOS establishing tunnels that the kernel's HRR would then tear down, creating the race condition. The BIOS vendor fixed it by leaving tunnel establishment to the kernel entirely. Given this, I think the retry patch is no longer needed for this specific platform. That said, the underlying race (HRR destroying BIOS tunnels → DPRX timeout → permanent DP IN removal) could still affect other USB4 v2 platforms where the BIOS does pre-establish tunnels. Would it still be worth considering either: a) increasing the default dprx_timeout, or b) at minimum, not permanently removing the DP IN adapter on the first DPRX failure? Thanks again for the guidance. Best regards, AceLan Kao.