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:
- Whether additional firmware diagnostics can identify the originating data-fabric block.
- Whether the missing 00:02.2 root port after this reset type is a known firmware issue.
- 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
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:
So far the reset happened three times across two months' per:
The symptom is same across three(all three happened during low/idle system usage):
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.
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:
I've tried to compile kernel PCIE_ECRC and turn on
"pcie_ports=native" "pci=ecrc=on", unfortunately it reportsacpi 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:
A somewhat maybe unrelated observation (since the first reset happend before the 96Gib momery swap):
cc @Nephyrin