Skip to content

Steam Machine recurrent random data-fabric sync-flood resets and missing Wi-Fi PCIe port after automatic reboot #2757

Description

@sg-qwt

I run my Fremont system 24/7 continuously as a mini PC. Over approximately six weeks, it has experienced three intermittent platform-level hard resets. I have not identified a reliable workload trigger.

Hopefully this is the right place to raise the issue:

  • Product: Valve Fremont revision 1
  • Board: Fremont revision 9

So far the reset happened three times across two months' per:

first occurrence 
6.18.37-valve1 firmware: F7F0106
`Jul 16 04:38:47.925709: x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event`
second occurrence
6.18.42-valve2 firmware: F7F0106
Aug 18 22:19:01.004092: x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event
third occurrence
6.18.45-valve1 firmware: F7F0108
Aug 27 16:30:36.988514: x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event

The symptom is same across three(all three happened during low/idle system usage):

  The machine intermittently hard-resets without an orderly shutdown. Linux reports:

  x86/amd: Previous system reset reason [0x08000800]:
  an uncorrected error caused a data fabric sync flood event

  The automatic reboot completes, but Wi-Fi is unavailable. A second manual reboot restores Wi-Fi.

There was no orderly shutdown sequence. I found no preceding kernel panic, OOM, thermal event, watchdog event, amdgpu reset/hang, MCE record, or saved pstore crash report.

After each data-fabric reset, PCIe root port 00:02.2 is absent. Consequently, the Qualcomm Wi-Fi endpoint is not enumerated.

Expected healthy topology:

00:02.2 AMD Phoenix GPP PCIe Root Port [1022:14ee]
└─ 06:00.0 Qualcomm QCNFA765 [17cb:1103]

Broken automatic-reboot topology:

00:02.2 missing
06:00.0 AMD Dummy Function [1002:145a]

The dummy function normally appears at 07:00.0; it moves to bus 06 because the missing Wi-Fi root port changes bus numbering.

After a manual reboot, 00:02.2 and [17cb:1103] return, ath11k_pci initializes, and wlan0 associates normally.

To complicate things a bit, I do swapped in my own memory and ssd, but both hardware worked reliably from an old gig before swapped in:

  • SSD: Crucial P3 Plus 2 TB
  • Memory: 2 x 48 GiB Crucial CT48G56C46S5.M16B1 5600 MT/s

I've tried to compile kernel PCIE_ECRC and turn on "pcie_ports=native" "pci=ecrc=on", unfortunately it reports acpi PNP0A08:00: _OSC: platform does not support [AER]

Therefore Linux cannot identify which fabric/PCIe component generated the uncorrectable error.

Suspected issue

A fatal AMD data-fabric/PCIe error triggers an emergency reset. That reset does not fully reinitialize or clear the state of PCIe root port 00:02.2, leaving the Wi-Fi PCIe path absent until another reboot.

The consistently missing Wi-Fi root port may indicate that this PCIe path participates in the original fabric error, although it could also be collateral damage from incomplete platform reset handling.

Some questions:

  1. Whether additional firmware diagnostics can identify the originating data-fabric block.
  2. Whether the missing 00:02.2 root port after this reset type is a known firmware issue.
  3. Whether a firmware update can expose or preserve AER/CPER error information.

A somewhat maybe unrelated observation (since the first reset happend before the 96Gib momery swap):

SMBIOS detects both 48 GiB modules correctly, but the physical memory array reports:

Maximum Capacity: 64 GiB

The OS maps and uses all 96 GiB. I guess 64 GiB SMBIOS limit is only a firmware-table error?

cc @Nephyrin

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions