Linux USB
 help / color / mirror / Atom feed
* Re: [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling
@ 2026-07-05 13:48 Neo
  2026-07-05 13:58 ` Neo
  0 siblings, 1 reply; 4+ messages in thread
From: Neo @ 2026-07-05 13:48 UTC (permalink / raw)
  To: Alan Borzeszkowski, linux-usb; +Cc: andreas.noever, westeri, YehezkelShB

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




^ permalink raw reply	[flat|nested] 4+ messages in thread
* [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling
@ 2026-07-03  3:49 Neo
  2026-07-03 16:48 ` Alan Borzeszkowski
  0 siblings, 1 reply; 4+ messages in thread
From: Neo @ 2026-07-03  3:49 UTC (permalink / raw)
  To: linux-usb; +Cc: andreas.noever, westeri, YehezkelShB

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


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-07-05 13:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-05 13:48 [PATCH RFC] thunderbolt: Add JHL9580 Barlow Ridge (TB5) ICM support — host_reset timeout blocking PCIe tunneling Neo
2026-07-05 13:58 ` Neo
  -- strict thread matches above, loose matches on Subject: below --
2026-07-03  3:49 Neo
2026-07-03 16:48 ` Alan Borzeszkowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox