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

[Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>]

Hi,

please share full dmesg (e.g., attached here) with Thunderbolt debug.
Include logs from MSI laptop and the TB4 laptop.

Also, up to last email you mention using same eGPU (RTX 5090) but then
it's RTX 3090 Ti. Which one is it?

Per your questions - there is no timeline for ICM support for Barlow
Ridge. Only software CM is supported.

You may also try updating/reinstalling eGPU box software using
manufacturer tool.


On Sun, 2026-07-05 at 21:58 +0800, Neo wrote:
> 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 softwar
> e CM (ICM not used, per your confirmation). Now: simply plugging in t
> he Thunderbolt cable causes a HARD system freeze — the kind where eve
> n 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 success
> ful,
>    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 su
> pport — host_reset timeout blocking PCIe tunneling
> 
> 
> Hi,
> 
> Please send full dmesg with 'thunderbolt.dyndbg=+p' parameter in linu
> x
> 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 fi
> > rst
> >  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
> 
> 
> 
>