I installed Fedora 41 KDE (not a live disk, installed) on a USB stick that I am booting from. It has power profiles daemon set to balanced. I have not encountered a reboot event in a few days of sleep/wake.
A few days later, I noticed there was amd-ucode updates on arch, so I installed those, and have not experienced another reboot since (fingers crossed). My PPD is also set to balanced here.
I am now running 6.13.7-arch1-1
From pacman logs
[2025-03-19T18:45:23-0400] [ALPM] upgraded amd-ucode (20250311.b69d4b74-2 ā 20250311.b69d4b74-3)
[2025-03-19T18:45:23-0400] [ALPM] upgraded linux-firmware-whence (20250311.b69d4b74-2 ā 20250311.b69d4b74-3)
[2025-03-19T18:45:24-0400] [ALPM] upgraded linux-firmware (20250311.b69d4b74-2 ā 20250311.b69d4b74-3)
I have been dailying my Framework again for a few weeks now, and no reboots have happened (fingers crossed).
Wow, this bug is persistent. Can you open a ticket with Framework about this? If I can repro Iāll do the same. Please encourage everyone else to do the same.
Might need to look at what changed between my current kernel and this new one. I am not having this yet on 6.14.9
CC @Matt_Hartley it appears the Ryzen AI 300 series boards also suffer from the Sync Flood issue. Please tell me that Framework engineers are aware of this and actively looking into it? This means every AMD board Framework has released suffers from this problem.
Yep, sometime around 6.13.7, one of those upgrades seemed to solve my Triple Fault issue. I have not had this problem since. I am currently running linux 6.14.10-arch1-1, core/linux-firmware 20250508.788aadc8-2, and core/amd-ucode 20250508.788aadc8-2.
However, I got tagged in this post the other day. I asked if they could check the S5_RESET_STATUS so we can be sure if itās FTR or Triple Fault but they havenāt replied. I am guessing it is Sync Flood because of the version of Linux (6.14.9) they are running. I havenāt seen anybody overtly reporting the Triple Fault 0x00800800 yet, but the Ryzen AI 300 series boards are confirmed to be experiencing the Sync Flood 0x08000800.
I appreciate the attention on this. This Sync Flood issue is particularly nasty because it seems to affect any and all boards on any and all distros/kernels. This thread, as well as the others replied in, and the GitHub issues all have these reports. It seems like itās hardware/firmware related. I fear that if it is not root caused by Framework engineering, whatever AMD board is released next will also have this issue. Iād suggest this thread be read and watched as the main Sync Flood thread.
Just like Matt mentioned, this issue is going to be my first focus of the day. Currently putting a fresh install of Arch on a Framework Laptop 13 Ryzen AI 300 series. Thanks a ton for sharing the GitHub issue and related threads, Iām gonna be pouring over those while I work on this.
I do share the sentiment most are sharing that it will still take a considerable amount of time to really narrow down the issue and give our engineers and AMD the information they need to act on this. We really appreciate everybodyās patience in the meantime. I hope weāre able to provide an update soon.
Iāve finally found a way to force this crash to happen essentially on demand with my hardware. Iām hoping weāre able to use that as a basis to find a fix for this issue, and with luck Iāll be able to deliver for information on this soon.
Unfortunately I donāt come bearing the best of news. Weāve been working in-house and with manufacturing partners trying to find consistent and reliable replication methods and havenāt been unsuccessful. The method Iād been leveraging to consistently crash my own AI 300 series Framework Laptop 13 was power adapter related and has been fixed with subsequent firmware updates.
We have gotten a couple of reports of the same sort of issue from Windows users, and Iāve been having some back and forths with the firmware team about it. Weāre doing everything we reasonably can and narrowing down the variables as much as we can. I still canāt provide an ETA, but work is ongoing.
After a timeout period, the psu will drop to 5V while in standby.
When powering on, it will switch back to 20V (36V for FW16). During the switch it forces the psu to 2.5 Watts. This switch causes the resume to fail.
I think the solution is for the EC to complete its switch to 20V before atemping to resume.
A good test for this would be:
resume with psu plugged in fails
resume with no psu attached works.
Can anyone seeing the problem try these two tests?
The correct solution though is a hardware change, placing larger capacitors in the power chain on the laptop side so they can store more power to absorb the short power glitches from the psu and cpu.
I have seen the psu glitch down to 2.5W and the CPU glitch up to 450W. These glitches are very short, e.g. 1-10ms
Hey, I might be having the same, or at least a very similar issue. I donāt get freezes or weird graphical glitches, the first thing I see after opening the lid is a black screen and the laptop starting to boot. Iām using a FW13 AMD Ryzen 7040, currently running Arch Linux with kernel version 6.16.3-zen1-1-zen
For the past two days the issue has been happening much more often (not sure if anything changed), so I did some digging, and this time I think I was able to find the relevant logs. Turns out I needed to run dmesg
x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event
Iām still getting this intermittently but often enough to be mildly irritating and the mesg I get in dmsg after itās happened is (at least the last time)
[ 2.012074] x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6 to reset control register 0xCF9
