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,

Thanks for the logs. From Thunderbolt perspective I don't see any
blaring issues. Few things to note.

I don't think this eGPU enclosure officially supports Linux. But then
at least the link should be established, I suppose.. You can check on
Windows if it works at all.

Also, your setup with 2gen older GPU and many pcie arguments in command
line (pci=realloc,assign-busses, [...],hpiosize=8K) and especially
"pcie_port_pm=off" probably has some influence on this issue.
Maybe things improve if all of those are removed?

On Sat, 2026-07-11 at 17:09 +0800, Neo wrote:
> Hi Alan,
>     
>     Thanks for the confirmation about software CM only. Understood
> that
>     there is no timeline for ICM support on Barlow Ridge.
>     
>     Re GPU: to clarify the confusion — the eGPU enclosure is a
> GIGABYTE
>     RTX 5090 AI BOX (which has a built-in 5090). In our testing, we
> have
>     an RTX 3090 Ti card plugged into the enclosure's PCIe slot. So:
>     
>       Enclosure:  GIGABYTE RTX 5090 AI BOX (JHL9580 Barlow Ridge)
>       Test GPU:   RTX 3090 Ti (inside the enclosure)
>     
>     MSI laptop full dmesg with Thunderbolt debug attached.
>     Kernel cmdline includes thunderbolt.dyndbg=+p .
>     
>     System details:
>       MSI laptop, Intel Core Ultra 9 275HX
>       Thunderbolt controller: JHL9580 Barlow Ridge Host 80G (lspci
> 04:00.0)
>       Kernel: 7.0.0-27-generic
>       NVIDIA driver: 595.71.05
>       434 Thunderbolt-related lines in dmesg
>     
>     The TB4 laptop dmesg is not immediately available. If essential
> for
>     comparison I can reproduce and capture it, but the primary bug
>     (hotplug crash) occurs on the MSI / Barlow Ridge system and the
>     attached log covers that.
>     
>     Cross-host experiment from earlier testing (referenced in bug
> 221716):
>     both TB4 and TB5 hosts exhibit the same hotplug crash, suggesting
> the
>     issue is on the enclosure/GPU side rather than host-specific.
>     
>     I'll try updating the eGPU box firmware with the manufacturer
> tool
>     and report back.
>     
>     Thanks,
>     Neo
> 
> 
> 	
> Neo
> liqys@vip.qq.com
> 
> 
> 
> 
> 原始邮件
> 发件人：Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
> 发件时间：2026年7月7日 22:56
> 收件人：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 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 the
> n
> 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 don
> > e
> >  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 SAM
> > E
> >  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 th
> > e
> >  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) on
> > ly
> >  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 do
> > ing
> >  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 stal
> > ls
> >     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 soft
> > war
> >  e CM (ICM not used, per your confirmation). Now: simply plugging i
> > n 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 succ
> > ess
> >  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 rule
> > s
> >  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 downstrea
> > m
> >  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 ru
> > n.
> >  
> >  
> >  === 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 its
> > elf
> >     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 NVIDI
> > A
> >     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 yo
> > ur
> >  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 l
> > inu
> >  x
> >  command line.
> >  
> >  Firmware Connection Manager (ICM) is not used with Barlow Ridge, o
> > nly
> >  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() ti
> > mes
> >  >  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 sh
> > ow
> >  >     "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 Ri
> > dge
> >  > ?
> >  >  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
> >  
> >  
> >  
> >  
>