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

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

No repository files or tests are named. Start by reviewing the reported x86/amd data-fabric reset reason, the healthy and broken PCI topology for root port 00:02.2, and the available AER/CPER and firmware diagnostics; done means identifying the originating component or documenting whether the missing Wi-Fi root port is a firmware reset-handling issue.