Running systemctl poweroff (or shutdown now) causes the machine to shut down and then immediately reboot instead of staying off. The machine goes dark for a few seconds, then the Framework logo appears and it boots back into Arch.
Kernel reset reason on every affected boot:
x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event
Occasionally:
x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6 to reset control register 0xCF9
Some key findings:
systemctl halt works perfectly. The machine stops and stays off. systemctl poweroff reliably triggers the sync flood and reboots.
What I’ve ruled out
Thermals. CPU ~51°C at time of events, well clear of throttle/critical thresholds
BIOS “boot on AC attach”. confirmed disabled
ACPI wakeup sources. all configured for S4 (hibernate), not S5, disabling all XHC/NHI wakeup sources made no difference
reboot=efi kernel parameter, tested, did not help
Studio Display / Thunderbolt. machine reboots with and without display connected
Current kernel parameters (for reference)
usbcore.autosuspend=-1 amdgpu.sg_display=0 thunderbolt.clx=false xhci_hcd.quirks=0x80
All added for unrelated reasons (suspend/resume USB issues, display handoff). None relevant to poweroff.
Is this a known issue being tracked for BIOS 03.05?
Which Linux distro are you using? Archlinux
(If rolling release, last date updated?) Today
Which kernel are you using? 6.19.10-arch1-1
Which BIOS version are you using? Insyde 03.04 (latest stable)
Which Framework Desktop model are you using? Framework Desktop, AMD Ryzen AI Max 300 Series (Strix Halo)
Particulary the bit that mentions pcie_ports=native pcie_ecrc=on
Summary:
You don’t mention which ssd/nvme devices you have, but they may be causing AER errors due to old firmware.
Setting the above kernel params lets the system report AER errors, and will say which device is causing a problem.
Thank you! I just tried running it with those boot parameters. The problem persisted and nothing in logs as far as I could tell. Had Claude double check the logs and it came back with the following reply:
Here’s what the logs tell us:
AER was active — both PCIe root ports got AER enabled with IRQs. The pcie_ports=native param worked.
Zero AER errors during shutdown — the journal ran cleanly all the way through systemd-shutdown[1]: Syncing filesystems… and then the journal stopped. No device threw a correctable or uncorrectable PCIe error that AER could catch.
Sync flood still happened — confirmed by boot 0’s reset reason: 0x08000800.
Conclusion: The sync flood occurs after the kernel hands off to firmware for ACPI S5 — after the journal stops, below the level AER can observe. No specific PCIe device is to blame. This rules out the forum suggestion (bad NVMe or other device causing AER errors that cascade into the sync flood).
The bug is squarely inside the BIOS’s ACPI S5 implementation. AER can’t see it because Linux is already out of the picture when it happens.
The forum reply doesn’t apply to your situation. BIOS 03.05 beta remains the only real path forward.
OK, it was worth a try. AER is not the only cause of “Sync Flood”.
Please create a new issue on the github (see link from previous message).
Making it clear that it relates to the FW Desktop and is a “FW Desktop Sync Flood at shutdown”. Thus making is separate issue from the FW16 issue I linked to above.