[BUG] AMD Data Fabric Sync Flood on Ryzen AI MAX+ 395 (Zen 5 / Strix Halo) — Uncorrected Error Causes Hard Reset with Empty vmcore
Kernel Version: 7.0.0-28-generic (Ubuntu 24.04.2, PREEMPT_DYNAMIC)
CPU: AMD Ryzen AI MAX+ 395 w/ Radeon 8060S (Zen 5, Strix Halo, family 0x1a, model 0x70, stepping 0x0)
iGPU: AMD Radeon 8060S (PCI ID 1002:1586, rev c1, RDNA 3.5)
BIOS: P10_F11_20_IEC0008_BI0010_AMI_120W (2026-01-13)
Memory: 128 GB LPDDR5X-8000 (8 × 16 GB Micron), No ECC
Kernel boot params:
BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=... ro quiet splash \
amdgpu.gttsize=81920 amdgpu.vm_size=128 amdgpu.vm_update_mode=3 \
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
[BUG] Summary
The system experiences a kernel panic / hard reset triggered by an AMD CPU data fabric sync flood event. The reset is instantaneous — the kernel produces no panic message, no call trace, and no register dump. The kdump mechanism captures the reset event but the vmcore is dump-incomplete (ring buffer = 0 bytes). The system restarts automatically without user intervention.
This is distinct from a normal kernel OOPS or panic — it is a hardware-level reset at the CPU die level, not a software-level abort.
[BUG] Root Cause: Data Fabric Sync Flood
On boot, the kernel reads the previous reset reason from AMD MSR registers:
[ 1.688183] x86/amd: Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event
The AMD Data Fabric is the internal interconnect network on Zen 5 dies that routes all communication between CPU cores, L3 cache, memory controllers, and IO dies. When the data fabric detects an uncorrected internal error, the AMD hardware specification mandates a Sync Flood — an immediate hard reset of the entire CPU die with no software intervention possible.
The uncorrected error source is unknown but could be:
- Memory bit flip — 128 GB LPDDR5X-8000 with NO ECC correction; a single bit flip in a data fabric register file can trigger this
- CPU silicon errata — Zen 5 (Strix Halo) is a new architecture (H1 2025); possible undocumented bugs in data fabric logic
- VRM/power fluctuation — Data fabric is extremely sensitive to voltage droops; transient undervoltage can cause computation errors in fabric links
- Temperature-induced instability — High APU thermal load may reduce logic stability margins
[BUG] Reproduction Timeline
2026-08-16 05:52:18 Kernel panic → hard reset (sync flood)
├── last records session as "crash (06:36)"
├── kexec triggered (kexec_cmd timestamp = 05:52)
├── vmcore: dump-incomplete (ring buffer = 0 bytes)
└── Reset reason: 0x08000800 (Data Fabric Sync Flood)
2026-08-16 05:53:09 Normal boot completes (GDM starts)
System uptime before crash: ~7 days 10.5 hours (since Aug 8 19:16)
Historical context: On Aug 8, the same system experienced 6 crashes within ~12 hours (all with reset reason 0x00200800 = ACPI power state transition, a different cause). After switching to kernel 7.0.0-28, the system was stable for 7+ days until this incident.
[BUG] Why vmcore is Empty
The sync flood is fundamentally different from a kernel panic:
- No panic message — The CPU halts all instruction execution within a single clock cycle. There is no time to print
Kernel panic or save a call trace.
- Ring buffer lost — The kernel ring buffer (dmesg) is in RAM; when the CPU resets, all RAM content is lost from the OS perspective.
- kdump partially works — kexec captures the reset event and boots the crash kernel, but the original kernel's memory is already lost. Only the file header is written (
dump-incomplete).
- MCE counters empty —
ras-mc-ctl confirms zero MCE/EDAC errors logged since boot. The hardware reset was too fast for the Machine Check Architecture to record the error.
This makes this bug class particularly difficult to debug — there is no software-level artifact to analyze.
[BUG] Additional Observations
AMDGPU iGPU instability during boot
On every boot (including the current one), the amdgpu driver reports a ring timeout during initialization:
[ 8.932234] amdgpu 0000:66:00.0: ring gfx_0.0.0 timeout,
signaled seq=2, emitted seq=5
[ 8.932240] amdgpu 0000:66:00.0: Starting gfx_0.0.0 ring reset
[ 8.932349] amdgpu 0000:66:00.0: Ring gfx_0.0.0 reset succeeded
[ 8.932350] amdgpu 0000:66:00.0: [drm] device wedged, but recovered through reset
This indicates the RDNA 3.5 iGPU has timing issues during early boot. While the driver recovers, it suggests the GPU subsystem may be a contributing factor to overall system instability (potential data fabric interference via PCIe).
Custom amdgpu parameters
amdgpu.vm_update_mode=3 # Immediate page table updates (not deferred)
amdgpu.gttsize=81920 # 80 GB GTT (vs default smaller allocation)
amdgpu.vm_size=128 # 128 GB per-process VM address space
vm_update_mode=3 makes the GPU more sensitive to page table errors — any invalid memory access triggers an immediate GPU fault rather than being deferred. This increases the probability of GPU faults propagating to the data fabric under heavy compute load.
No ECC on system memory
Error Correction Type: None
128 GB of LPDDR5X-8000 with no ECC means single-bit errors go undetected and uncorrected. In a data fabric context, a memory ECC event that propagates to a data fabric register can trigger a sync flood.
[BUG] System Configuration Details
PCIe Topology (relevant devices)
66:00.0 Display controller: AMD Radeon Graphics [1002:1586] (RDNA 3.5 iGPU)
66:00.1 Audio device: AMD Rembrandt Radeon HD Audio [1002:1640]
67:00.0 Processing accelerators: AMD Device [1022:150d] (XDNA NPU)
67:00.1 Processing accelerators: AMD XDNA Device [1022:17f0] (NPU firmware)
68:00.0/3/5 USB controller: AMD Strix Point USB4 [1022:1588/1589/158d]
62:00.0 Network controller: MediaTek MT7925 802.11be [14c3:7925]
61:00.0/63:00.0 Ethernet: Realtek RTL8125 2.5GbE [10ec:8125] × 2
64:00.0 Storage: Sandisk SN740 NVMe [1e4b:1602]
CPU Features
AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
Family: 0x1a (Zen 5), Model: 0x70 (Strix Halo), Stepping: 0x0
32 cores / 32 threads
Vector extensions: AVX512F, AVX512DQ, AVX512IFMA, AVX512VBMI, AVX512_VBMI2,
AVX512VL, AVX512_VNNI, AVX512_VP2INTERSECT, AVX512_VPOPCNTDQ,
AVX512_BF16, AVX512_BITALG, AVX512BW, AVX512CD,
AVX_VNNI, AVX2, AVX
Memory Configuration
8 × 16 GB LPDDR5X-8000 (Micron), total 128 GB
No ECC / No ECC — all memory errors are silent
Kernel sees 115 GB (5 GB reserved for GTT/iGPU/PCIe holes)
Current usage: 4.6 GB used / 105 GB free / 110 GB available
Swap: 8 GB (unused)
kdump Configuration
USE_KDUMP=1
KDUMP_KERNEL=/var/lib/kdump/vmlinuz
KDUMP_INITRD=/var/lib/kdump/initrd.img
KDUMP_COREDIR="/var/crash"
# KDUMP_COMPRESSION not set (should be lz4)
# KDUMP_NUM_DUMPS not set (should limit to 5)
kernel.panic = 0 (no auto-reboot on panic)
[BUG] Requested Actions
-
Document the 0x08000800 reset reason code in the AMD x86/AMD kernel documentation so that the reset reason is properly decoded in dmesg output.
-
Investigate Zen 5 Strix Halo data fabric errata — Is this a known silicon bug? Are there any workarounds (BIOS settings, kernel parameters, microcode updates)?
-
Improve kdump reliability for sync flood events — Currently, sync floods produce empty vmcores. Could the crash kernel capture the MCE registers before the data fabric is fully reset? Could the kexec crash entry point be made more resilient to hard resets?
-
Provide guidance on ECC-less LPDDR5X systems — The Strix Halo platform uses soldered LPDDR5X without ECC. What mitigation strategies does AMD recommend for data fabric stability on such configurations?
-
amdgpu ring timeout during boot — Is the gfx_0.0.0 ring timeout at boot a known issue on RDNA 3.5? Could this be related to data fabric instability?
[BUG] Workarounds Currently Applied
- Running kernel 7.0.0-28 (switched from 6.14/6.17 after Aug 8 instability)
amdgpu.vm_update_mode=3 for GPU performance stabilityamdgpu.gttsize=81920 for large model inference workloads- crashkernel reserved (2G-4G:320M, 4G-32G:512M, 32G-64G:1024M, 64G-128G:2048M, 128G-:4096M)
Reset reason codes observed on this system:
| Code |
Meaning |
Occurrence |
| 0x08000800 |
Data Fabric Sync Flood (uncorrected error) |
2026-08-16 (this report) |
| 0x00200800 |
ACPI Power State Transition |
2026-08-08 (6 occurrences) |
| 0x00000000 |
Normal boot (no prior reset) |
Most boots |
[BUG] AMD Data Fabric Sync Flood on Ryzen AI MAX+ 395 (Zen 5 / Strix Halo) — Uncorrected Error Causes Hard Reset with Empty vmcore
Kernel Version: 7.0.0-28-generic (Ubuntu 24.04.2, PREEMPT_DYNAMIC)
CPU: AMD Ryzen AI MAX+ 395 w/ Radeon 8060S (Zen 5, Strix Halo, family 0x1a, model 0x70, stepping 0x0)
iGPU: AMD Radeon 8060S (PCI ID 1002:1586, rev c1, RDNA 3.5)
BIOS: P10_F11_20_IEC0008_BI0010_AMI_120W (2026-01-13)
Memory: 128 GB LPDDR5X-8000 (8 × 16 GB Micron), No ECC
Kernel boot params:
[BUG] Summary
The system experiences a kernel panic / hard reset triggered by an AMD CPU data fabric sync flood event. The reset is instantaneous — the kernel produces no panic message, no call trace, and no register dump. The kdump mechanism captures the reset event but the vmcore is
dump-incomplete(ring buffer = 0 bytes). The system restarts automatically without user intervention.This is distinct from a normal kernel OOPS or panic — it is a hardware-level reset at the CPU die level, not a software-level abort.
[BUG] Root Cause: Data Fabric Sync Flood
On boot, the kernel reads the previous reset reason from AMD MSR registers:
The AMD Data Fabric is the internal interconnect network on Zen 5 dies that routes all communication between CPU cores, L3 cache, memory controllers, and IO dies. When the data fabric detects an uncorrected internal error, the AMD hardware specification mandates a Sync Flood — an immediate hard reset of the entire CPU die with no software intervention possible.
The uncorrected error source is unknown but could be:
[BUG] Reproduction Timeline
Historical context: On Aug 8, the same system experienced 6 crashes within ~12 hours (all with reset reason
0x00200800= ACPI power state transition, a different cause). After switching to kernel 7.0.0-28, the system was stable for 7+ days until this incident.[BUG] Why vmcore is Empty
The sync flood is fundamentally different from a kernel panic:
Kernel panicor save a call trace.dump-incomplete).ras-mc-ctlconfirms zero MCE/EDAC errors logged since boot. The hardware reset was too fast for the Machine Check Architecture to record the error.This makes this bug class particularly difficult to debug — there is no software-level artifact to analyze.
[BUG] Additional Observations
AMDGPU iGPU instability during boot
On every boot (including the current one), the amdgpu driver reports a ring timeout during initialization:
This indicates the RDNA 3.5 iGPU has timing issues during early boot. While the driver recovers, it suggests the GPU subsystem may be a contributing factor to overall system instability (potential data fabric interference via PCIe).
Custom amdgpu parameters
vm_update_mode=3makes the GPU more sensitive to page table errors — any invalid memory access triggers an immediate GPU fault rather than being deferred. This increases the probability of GPU faults propagating to the data fabric under heavy compute load.No ECC on system memory
128 GB of LPDDR5X-8000 with no ECC means single-bit errors go undetected and uncorrected. In a data fabric context, a memory ECC event that propagates to a data fabric register can trigger a sync flood.
[BUG] System Configuration Details
PCIe Topology (relevant devices)
CPU Features
Memory Configuration
kdump Configuration
[BUG] Requested Actions
Document the 0x08000800 reset reason code in the AMD x86/AMD kernel documentation so that the reset reason is properly decoded in
dmesgoutput.Investigate Zen 5 Strix Halo data fabric errata — Is this a known silicon bug? Are there any workarounds (BIOS settings, kernel parameters, microcode updates)?
Improve kdump reliability for sync flood events — Currently, sync floods produce empty vmcores. Could the crash kernel capture the MCE registers before the data fabric is fully reset? Could the kexec crash entry point be made more resilient to hard resets?
Provide guidance on ECC-less LPDDR5X systems — The Strix Halo platform uses soldered LPDDR5X without ECC. What mitigation strategies does AMD recommend for data fabric stability on such configurations?
amdgpu ring timeout during boot — Is the gfx_0.0.0 ring timeout at boot a known issue on RDNA 3.5? Could this be related to data fabric instability?
[BUG] Workarounds Currently Applied
amdgpu.vm_update_mode=3for GPU performance stabilityamdgpu.gttsize=81920for large model inference workloadsReset reason codes observed on this system: