Re: [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling

[Neo <liqys@vip.qq.com>]

Hi Alan,

Please disregard my previous email's suspect list — I've since done
a cross-host experiment that changes the picture completely.

=== CROSS-HOST TEST ===

I plugged the SAME GIGABYTE AORUS RTX 3090 Ti AI BOX (with the SAME
TB5 cable) into a Thunderbolt 4 laptop (no dGPU, Titan Ridge host
router):

  Result: The TB4 laptop ALSO freezes instantly on hot-plug.

  BUT: On TB4, unplugging the cable RECOVERS the system normally.

  Reproduced on multiple computers, both TB4 and TB5 hosts.

=== WHAT THIS MEANS ===

TB4 (Titan Ridge) and TB5 (Barlow Ridge) are completely different host
router silicon with different kernel code paths. Both freeze on the
same eGPU dock hot-plug → the common denominator is the eGPU dock or
the 3090 Ti card, NOT the JHL9580.

The difference in recovery behavior (TB4 recovers, TB5 doesn't) only
tells us JHL9580 has weaker fault tolerance than Titan Ridge — it
follows a misbehaving downstream device into a permanent bus-level
deadlock.

=== REVISED ROOT CAUSE ===

The 3090 Ti card (or the GIGABYTE dock's TB firmware) is likely doing
something unexpected during PCIe link training on hot-plug that stalls
the host's PCIe root complex. The software CM's tb_scan_switch() never
gets a chance to run because the bus is already dead.

This would also explain the original Bug 221716 PCIe tunnel issue —
the downstream device never completes initial enumeration, so the
software CM naturally sees nothing.

=== QUESTIONS ===

a) Is it known for certain eGPU cards/docks to cause PCIe bus stalls
   during TB hot-plug? Any known workarounds?

b) Does the kernel's software CM have a quirk/blacklist mechanism for
   misbehaving downstream devices?

c) For the JHL9580 permanent-freeze case: are there PCIe completion
   timeout or AER settings that could prevent the host router from
   following a bad downstream device into a deadlock?

d) I'll test cold-boot (shutdown → plug eGPU → power on) next. If
   that works, the dock/card is fine — the bug is specifically in
   the hot-plug path. Makes sense?

Thanks, and sorry for the noise — the cross-host test was a late
addition but it completely changed the diagnosis.

Neo

	
Neo
liqys@vip.qq.com




原始邮件
发件人：Neo <liqys@vip.qq.com>
发件时间：2026年7月5日 21:48
收件人：Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>, linux-usb <linux-usb@vger.kernel.org>
抄送：andreas.noever <andreas.noever@gmail.com>, westeri <westeri@kernel.org>, YehezkelShB <YehezkelShB@gmail.com>
主题：Re: [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling


Hi Alan,


Following up on Bug 221716 — I have a new, more severe symptom on the same hardware.


Previously we discussed PCIe tunneling not establishing under software CM (ICM not used, per your confirmation). Now: simply plugging in the Thunderbolt cable causes a HARD system freeze — the kind where even kdump cannot fire.


=== SYSTEM ===
  Laptop:   MSI Vector 16 HX AI A2XWJG
  CPU:      Intel Core Ultra 9 275HX (Meteor Lake)
  dGPU:     NVIDIA RTX 5090 Max-Q [10de:2c18] (built-in)
  eGPU:     GIGABYTE AORUS RTX5090 AI BOX (JHL9580 downstream)
  BIOS:     E15M3IMS.117 (2026-04-17)
  Kernel:   7.0.0-27-generic
  NVIDIA:   595.71.05 open kernel module
  NHI:      8086:5781 (JHL9580 Barlow Ridge)


=== WHAT HAPPENED ===


1. Booted with thunderbolt.dyndbg=+p (software CM, security=user).
   Thunderbolt driver initialized cleanly — host router reset successful,
   control channel created, DROM read, all 23 ports enumerated.


2. Plugged in the GIGABYTE eGPU dock's Thunderbolt 5 cable.


3. System instantly froze:
   - Screen frozen (no cursor movement)
   - No USB/keyboard response
   - Magic SysRq unresponsive
   - Unplugging the cable did NOT recover the system
   - Had to hold power button for forced shutdown


=== ZERO LOGS (hardest possible freeze) ===


This is the critical finding: the kernel wrote ABSOLUTELY NOTHING
related to the hot-plug event. The full crash-boot journal is 47,338
lines of normal system operation; the last lines are (unrelated):


  Jul 05 21:24:04 x systemd[3382]: Started searxng.service.
  Jul 05 21:24:04 x (start.sh)[9986]: ... Failed at step EXEC ...
  [then nothing until forced power-off at ~21:31]


Thunderbolt in crash-boot kernel log: 162 lines, ALL from driver init:


  thunderbolt 0000:04:00.0: host router reset successful
  thunderbolt 0000:04:00.0: using software connection manager
  thunderbolt 0000:04:00.0: NHI initialized, starting thunderbolt
  thunderbolt 0000:04:00.0: 0: DROM version: 3
  thunderbolt 0000:04:00.0: 0: uid: 0xb188f3000000b48a
  thunderbolt 0000:04:00.0: security level set to user
  [... port enumeration, TMU init, DP IN — all clean ...]


NO hot-plug event. NO interrupt logged. NO error. NO timeout.


In the user-space journal, no thunderbolt-related message at all
between boot and freeze. bolt.service started cleanly at 21:21:10,
then nothing.


kdump status: crashkernel was loaded (kexec_crash_loaded=1 on the
current boot), but the previous boot produced NO vmcore. This rules
out a kernel panic or oops — the CPU stopped executing entirely
before any fault handler could run. Consistent with a PCIe bus-level
deadlock or the JHL9580 host router firmware crashing on downstream
device detection.


Even thunderbolt.dyndbg=+p (full dynamic debug on all tb modules)
produced zero output at plug time. The hot-plug interrupt either
never fired, or the CPU was already frozen before the ISR could run.


=== PREVIOUS PCIe TUNNEL ISSUE (Bug 221716 context) ===


On cold boot with the eGPU already connected, and also on software CM
with the eGPU disconnected: the host router initializes fine but
tb_scan_switch() sees no downstream device (all ports link=none).


The hot-plug hard freeze is a NEW, more severe symptom that blocks any
further debugging of the PCIe tunnel issue.


=== SUSPECTS ===


1. JHL9580 hardware/firmware bug: the Barlow Ridge host router itself
   crashes when it detects a downstream TB5 device via hot-plug.


2. NVIDIA driver interference: the built-in RTX 5090 Max-Q (01:00.0,
   nvidia 595.71.05) is on the same PCIe domain as the TB upstream
   bridge (02:00.0). The nvidia driver may react to a second NVIDIA
   GPU appearing on the bus and trigger a bus-level fault.


3. MSI BIOS: E15M3IMS.117 (2026-04-17) is the latest available.
   It exposes zero Thunderbolt configuration options (no security
   level toggle, no legacy mode). Unknown whether the firmware
   properly handles JHL9580 downstream hot-plug events at all.


=== NEXT STEPS (before I test again) ===


Before I try anything else that might corrupt my NVMe, I'd like your
guidance:


  a) Is the JHL9580 hot-plug hard-freeze a known issue?
  b) Should I try cold-booting with the eGPU pre-connected?
  c) Would unloading nvidia/nvidia-modeset before plugging help
     isolate the cause?
  d) Is there a register dump or debug step I can take via cold-boot
     (eGPU connected from power-on) to gather useful data?


Also: I noticed the upstream kernel (7.2-rc1) still has no JHL9580
entries in get_upstream_port() or icm_probe(). Is there a timeline
or WIP branch for Barlow Ridge support?


Thanks,
Neo

Neo
liqys@vip.qq.com




原始邮件
发件人：Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
发件时间：2026年7月4日 00:48
收件人：Neo <liqys@vip.qq.com>, linux-usb <linux-usb@vger.kernel.org>
抄送：andreas.noever <andreas.noever@gmail.com>, westeri <westeri@kernel.org>, YehezkelShB <YehezkelShB@gmail.com>
主题：Re: [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling


Hi,

Please send full dmesg with 'thunderbolt.dyndbg=+p' parameter in linux
command line.

Firmware Connection Manager (ICM) is not used with Barlow Ridge, only
software CM.

On Fri, 2026-07-03 at 11:49 +0800, Neo wrote:
> Hi maintainers,
> 
> 
> JHL9580 Barlow Ridge (8086:5780 bridge, 8086:5781 NHI), Intel's first
> Thunderbolt 5 / USB4 v2 host controller, has incomplete support in
> the
> kernel through v7.2-rc1. The host router reset times out and PCIe
> tunneling is non-functional, making eGPU use impossible.
> 
> 
> === Problem Summary ===
> 
> 
> 1. get_upstream_port() in icm.c does not recognize Barlow Ridge
> bridge
>    (0x5780). Neither does icm_probe() handle the NHI (0x5781).
> 
> 
> 2. With these fixed, icm_firmware_reset() → pcie2cio_write() times
> out
>    (-110) on Barlow Ridge. Neither icm_ar_cio_reset (0x50/BIT(9)) nor
>    icm_tr_cio_reset (0x777/BIT(1)) work.
> 
> 
> 3. Without ICM firmware running, REG_FW_STS (0x39944) is read-only
> and
>    writes are silently ignored. USB3 tunneling works (XHCI pass-
> through)
>    but PCIe tunnels are never established.
> 
> 
> 4. Even with software CM (tb_acpi_is_native()=1), USB4 ports show
>    "link: none" and the eGPU GPU never appears in lspci.
> 
> 
> === Hardware ===
> 
> 
>   Host: MSI MS-15M3 (E15M3IMS.117 BIOS, 2026-04-17)
>   CPU: Intel Arrow Lake-HX Ultra 9 275HX
>   TB5: Intel JHL9580 Barlow Ridge [8086:5780]/[8086:5781] (rev 84)
>   eGPU: GIGABYTE AORUS RTX5090 AI BOX (USB4)
>   OS: Ubuntu 26.04, kernel 7.0.0-27 (same issue on 7.0.0-22)
> 
> 
> === Patch Attempted (works up to firmware start) ===
> 
> 
> --- a/drivers/thunderbolt/icm.c
> +++ b/drivers/thunderbolt/icm.c
> @@ get_upstream_port():
> +     case 0x5780: /* JHL9580 Barlow Ridge Host Bridge */
> 
> 
> @@ icm_probe():
> +     case 0x5781: /* JHL9580 Barlow Ridge NHI */
> +           icm->max_boot_acl = ICM_AR_PREBOOT_ACL_ENTRIES;
> +           icm->can_upgrade_nvm = !x86_apple_machine;
> +           icm->is_supported = icm_ar_is_supported;
> +           icm->cio_reset = icm_ar_cio_reset;
> +           icm->get_mode = icm_ar_get_mode;
> +           icm->get_route = icm_ar_get_route;
> +           icm->save_devices = icm_fr_save_devices;
> +           icm->driver_ready = icm_ar_driver_ready;
> +           icm->device_connected = icm_fr_device_connected;
> +           icm->device_disconnected = icm_fr_device_disconnected;
> +           icm->xdomain_connected = icm_fr_xdomain_connected;
> +           icm->xdomain_disconnected = icm_fr_xdomain_disconnected;
> +           tb->cm_ops = &icm_ar_ops;
> +           break;
> 
> 
> Result: icm_probe succeeds, firmware_start begins, but
> icm_firmware_reset → pcie2cio_write times out.
> 
> 
> === dmesg ===
> 
> 
>   thunderbolt 0000:04:00.0: timeout resetting host router
>   (REG_RESET HRR remains 0x01 indefinitely; extended to 5000ms, no
> change)
> 
> 
> === Questions ===
> 
> 
> 1. What is the correct CIO reset sequence for Barlow Ridge?
> 2. Is the ICM firmware interface different from Alpine/Titan Ridge?
> 3. Are there plans to add native Barlow Ridge support to icm.c?
> 4. Should Barlow Ridge use software CM exclusively (skip ICM)?
> 
> 
> Full diagnostic logs, lspci, and ACPI DSDT excerpt available on
> request.
> Test hardware available for any proposed patches.
> 
> 
> Thank you,
> 
> Neo
> liqys@vip.qq.com