Linux PCI subsystem development
 help / color / mirror / Atom feed
* [BUG] PCI/USB4: AMD Phoenix 1022:14ef runtime suspend prevents JHL9480 downstream enumeration
@ 2026-09-19 12:39 Freeman Z
  2026-09-21  5:04 ` Mika Westerberg
  0 siblings, 1 reply; 41+ messages in thread
From: Freeman Z @ 2026-09-19 12:39 UTC (permalink / raw)
  To: linux-pci@vger.kernel.org, linux-usb@vger.kernel.org
  Cc: bhelgaas@google.com, westeri@kernel.org, andreas.noever@gmail.com,
	YehezkelShB@gmail.com, rafael@kernel.org,
	linux-pm@vger.kernel.org

Hello,

I am seeing a reproducible USB4/PCIe runtime-PM problem on an ASUS ROG
Flow X13 GV302XV (Ryzen 9 7940HS / Phoenix) with a Kensington SD5000T5
EQ Thunderbolt 5 dock connected to the laptop's USB4 host port.

The failure is reproducible with the official Arch Linux Live ISO using
Arch's stock `linux` kernel:

    7.2.2-arch1-1

I have not yet tested a self-built kernel.org mainline/vanilla kernel.
I can test patches, or collect additional traces if requested.

Summary
=======

The AMD Family 19h USB4/Thunderbolt PCIe tunnel at 0000:00:04.1
(1022:14ef) runtime-suspends while the Thunderbolt dock is connected.

In the failure state:

    /sys/bus/pci/devices/0000:00:04.1/power/control
        auto

    /sys/bus/pci/devices/0000:00:04.1/power/runtime_status
        suspended

    /sys/bus/pci/devices/0000:09:00.0
        does not exist

The Thunderbolt subsystem does detect the dock itself, but the
downstream Intel JHL9480/Barlow Ridge PCIe hierarchy is absent.

Without running lspci, I execute only:

    echo on > /sys/bus/pci/devices/0000:00:04.1/power/control

Immediately afterwards:

    /sys/bus/pci/devices/0000:00:04.1/power/runtime_status
        active

    /sys/bus/pci/devices/0000:09:00.0
        exists

and the downstream JHL9480 hierarchy, USB peripherals, and Ethernet
adapter behind the dock become available.

Reading PCI configuration space with:

    lspci >/dev/null

also wakes the topology, which is how I first noticed the issue.

Hardware
========

Laptop:
    ASUS ROG Flow X13 GV302XV
    AMD Ryzen 9 7940HS (Phoenix)
    AMD Radeon 780M iGPU
    NVIDIA GeForce RTX 4060 Laptop GPU

Dock:
    Kensington SD5000T5 EQ Thunderbolt 5 dock
    Connected through the laptop's AMD Phoenix USB4 host port

Recovered PCI topology identifies:

    00:04.1 PCI bridge [0604]:
      Advanced Micro Devices, Inc. [AMD]
      Family 19h USB4/Thunderbolt PCIe tunnel [1022:14ef]

    09:00.0 PCI bridge [0604]:
      Intel Corporation JHL9480 Thunderbolt 5 80/120G Bridge
      [Barlow Ridge Hub 80G 2023] [8086:5786] (rev 84)

    0a:00.0 / 0a:01.0 / 0a:02.0 / 0a:03.0 / 0a:04.0:
      Intel JHL9480 Thunderbolt 5 bridges [8086:5786]

    0c:00.0 USB controller [0c03]:
      Intel Corporation JHL9480 Thunderbolt 5 80/120G USB Controller
      [8086:5787]

The working PCI tree is:

    0000:00:04.1
      -> 0000:09:00.0
         -> 0000:0a:01.0
            -> 0000:0c:00.0
               -> downstream USB buses/devices

Arch Linux reproduction
=======================

I booted the official Arch Linux Live ISO with the dock attached.

Before running lspci or any hardware inventory tool, I observed:

    # cat /sys/bus/pci/devices/0000:00:04.1/power/control
    auto

    # cat /sys/bus/pci/devices/0000:00:04.1/power/runtime_status
    suspended

    # test -e /sys/bus/pci/devices/0000:09:00.0 &&
      echo present || echo missing
    missing

I captured journalctl -k -b and dmesg at this point.

The failure-state boot log contains:

    pci 0000:00:04.1: [1022:14ef] type 01 class 0x060400 PCIe Root Port
    pci 0000:00:04.1: PCI bridge to [bus 09-68]

and the Thunderbolt subsystem detects the dock:

    thunderbolt 0-2: new device found, vendor=0x1b device=0x11
    thunderbolt 0-2: Kensington SD5000T5 EQ Thunderbolt 5 Dock

However, the failure-state log contains no 0000:09:00.0 PCI device.

The ACPI/USB4 log also says:

    ACPI: USB4 _OSC: OS supports USB3+ DisplayPort+ PCIe+ XDomain+
    ACPI: USB4 _OSC: OS controls USB3+ DisplayPort+ PCIe+ XDomain+

I then ran only:

    echo on > /sys/bus/pci/devices/0000:00:04.1/power/control

After a few seconds:

    # cat /sys/bus/pci/devices/0000:00:04.1/power/runtime_status
    active

    # test -e /sys/bus/pci/devices/0000:09:00.0 &&
      echo present || echo missing
    present

The dock USB devices and Ethernet adapter recovered at the same time.

Only after this recovery did I run lspci, which showed the JHL9480
devices listed above.

Other kernels / environments
============================

The same enumeration problem has also been observed with:

    linux-cachyos 7.2.3
    linux-cachyos 7.2.4
    linux-cachyos 7.2.6
    linux-cachyos-lts 6.18.x
    CachyOS Live USB environment

Because it also reproduces on 6.18.x and I do not have a known
last-good kernel, I am not marking this as a regression and I do not
currently have a first-bad commit.

Workarounds and negative tests
==============================

A local udev rule that forces only 0000:00:04.1 active reliably avoids
the enumeration failure:

    ACTION=="add", SUBSYSTEM=="pci", KERNEL=="0000:00:04.1", \
    TEST=="power/control", ATTR{power/control}="on"

The global kernel option:

    pcie_port_pm=off

also prevents the enumeration failure, but is undesirable as a
permanent workaround because it disables PCIe port PM globally.

Forcing already-enumerated xHCI controllers to power/control=on did
not fix the issue.

An ASUS EC/hard reset did not fix the issue.

Additional shutdown/display observation
=======================================

This is not the primary subject of the report, but the same setup also
has intermittent display and late shutdown/reboot problems.

On Arch stock 7.2.2-arch1-1 I reproduced a late reboot hang after
systemd had already reached System Reboot. The console eventually
showed:

    INFO: task shutdown:1 blocked for more than 122 seconds.
    Not tainted 7.2.2-arch1-1 #1

Immediately before that there were repeated USB U1 transition failures
for a downstream USB device. Powering off the dock after the shutdown
was already stuck did not make the reboot continue.

The Arch boot log also contains:

    thunderbolt 0000:6b:00.6: 0: failed to allocate DP resource for port 7

I mention this only as potentially related context; I don't think 
that the shutdown/display symptoms and the deterministic PCIe
enumeration failure have the same root cause.

I have full failure-state dmesg and journalctl logs from the Arch Live
test, captured before waking 0000:00:04.1, and can provide them on
request.

CachyOS tracking issue: https://github.com/CachyOS/linux-cachyos/issues/1057

Thanks.

^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2026-10-09 14:55 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-19 12:39 [BUG] PCI/USB4: AMD Phoenix 1022:14ef runtime suspend prevents JHL9480 downstream enumeration Freeman Z
2026-09-21  5:04 ` Mika Westerberg
2026-09-21 15:24   ` Mario Limonciello
2026-09-22 16:40     ` Freeman Z
2026-09-22 17:02       ` Kovacs, Alexander
2026-09-22 17:03         ` Kovacs, Alexander
2026-09-22 19:54       ` Kovacs, Alexander
2026-09-22 20:00         ` Mario Limonciello
2026-09-23 11:51           ` Freeman Z
2026-09-23 12:26             ` Kovacs, Alexander
2026-09-23 12:35               ` Mario Limonciello
2026-09-23 19:37             ` Kovacs, Alexander
2026-09-24  7:18               ` Freeman Z
2026-09-25  5:27                 ` Mika Westerberg
2026-09-25  9:38                   ` Freeman Z
2026-09-25 11:31                     ` Freeman Z
2026-09-25 11:50                       ` Mika Westerberg
2026-09-25 14:10                         ` Mario Limonciello
2026-09-25 15:12                           ` Freeman Z
2026-09-25 15:24                             ` Mario Limonciello
2026-09-25 15:48                               ` Freeman Z
2026-10-01 14:54                                 ` Kovacs, Alexander
2026-10-01 18:28                                   ` Freeman Z
2026-10-05 14:35                                     ` Kovacs, Alexander
2026-10-05 15:39                                       ` Freeman Z
2026-10-05 17:01                                         ` Kovacs, Alexander
2026-10-05 17:10                                           ` Freeman Z
2026-10-06 14:33                                             ` Kovacs, Alexander
2026-10-06 14:37                                               ` Mario Limonciello
2026-10-06 16:33                                                 ` Freeman Z
2026-10-06 17:12                                                   ` Kovacs, Alexander
2026-10-06 18:45                                                     ` Freeman Z
2026-10-06 19:18                                                       ` Kovacs, Alexander
2026-10-06 19:33                                                         ` Freeman Z
2026-10-06 19:53                                                         ` Kovacs, Alexander
2026-10-06 21:04                                                           ` Freeman Z
2026-10-09 12:47                                                             ` Kovacs, Alexander
2026-10-09 13:02                                                               ` Freeman Z
2026-10-09 13:39                                                                 ` Kovacs, Alexander
2026-10-09 14:54                                                                   ` Freeman Z
2026-09-25 14:03                       ` Kovacs, Alexander

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