Same with me. Recently tried Fedora with the latest kernel (6.13.5) and got hit with the PSR issue. This has been going on for so long, not sure why this isn’t reflected in the Linux installation guides @Matt_Hartley
Not seeing this in bugzilla, which indicates it has not been reported yet. I run multiple machines all day, not seeing this on Fedora Workstation (GNOME).
- Is this Framework Laptop 13 Ryzen 7040 Series or Framework Laptop 16?
- List what you have attached at the moment, displays if attached and how (expansion cards, hubs, etc).
- Verify your grub file has only rd.luks.uuid=luks-xxxxxxxxxxxxxx (if used) and rhgb quiet. There should be no legacy AMD grub parameters present at this time.
- Steps to reproduce this?
@Jesse_Darnley can I get a repro on this, Fedora 41 Plasma please. If we find an issue, please file a Fedora Bug report.
Looks like it relates to https://gitlab.freedesktop.org/drm/amd/-/issues/3647
Jesse, let’s test this against downloaded mp4 video and YouTube, Chrome and Firefox. Testing against internal display only for the moment.
It’s not Framework-specific, it’s been reported on other AMD systems too, including Lenovo and HP laptops, as well as both the Framework 13 and 16—see the reports in the thread linked earlier here: Fedora KDE becomes suddenly slow - #14 by Julian_Stecklina
Unfortunately as far as I know, no one’s found a way to reliably reproduce it yet. There are a few reports that it tends to occur more often while playing video, and I’ve experienced this myself, but it’s still very inconsistent and intermittent. (There was about a week of regular usage between when I reenabled PSR after upgrading to kernel 6.13.5, and when the issue recurred again.)
No problem, I’ll get a fresh install of Plasma 41 going today and see if I can spot any noticeable trends. Just to be thorough, I’ll try a video in a few formats just to see if it comes down to a specific hardware decoder/encoder being utilized.
1 Like
An confirming for Jesse’s testing: we have no extra kernel parameters in place, correct? Should be default settings only.
Oh right, one other bit of info that might be useful for testing: the issue always seems to be accompanied by the following message repeatedly appearing in the system journal:
kernel: amdgpu 0000:c1:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
However, when I have PSR enabled, the same error message sometimes shows up in the system journal without the bug visibly being triggered—but in that case the error only shows up once or twice, while when the bug fully occurs and the system starts responding extremely slowly, it’s accompanied by a flood of that error message (over 100 times in the span of a couple minutes last time it happened).
When PSR is disabled, I’ve never observed either the bug or the above error message.
I do currently have extra kernel parameters in place right now but it’s also happened when I only had default parameters.
Sorry at the moment I have only Windows setup in the machine, but apparently as Amaranth is saying, it is not framework specific (I didn’t knew that).
Anyway, I had the issue on unchanged Fedora Workstation and unchanged Ubuntu (24.04.2 LTS and also 24.10), no grub parameters changed.
- Framework Laptop 13 Ryzen 7040 Series
- internal display, 2x USB-C, 1x HDMI, 1x USB-A (but nothing attached there)
- not charging (not sure if relevant)
- Only ever happened when watching Youtube in Firefox (but that is the only browser I use). Kinda hard to reproduce, just out of the sudden on 1 or 2 random days of the week it happens.
Honestly these kid of things should never be added to a installation guide. They can cause other issues and the user would need to remember at some point remove them.
Maybe in a tips and tricks kind of additional guide but never in a official installation guide.
Also as this seems to be more of kernel issue/kernel driver issue and for some reason doesnt happen to everybody. Personally I have not seen rhis happen on my FW13 with Aurora installed.Although my laptop usage is pretty light mostly Firefox/youtube/videos etc basic stuff
Just adding my two sats here. This issue is practically impossible to replicate with any degree of repeatability. It usually occurs when watching VP9 encoded videos on Firefox, one suggestion was to force AV1 encodes only, which I did but still continued to intermittently see this issue. I started using Brave and did not experience the issue again but now since Firefox 136 with AMD HW acceleration enabled, I havn’t experienced the issue whilst using that browser.
When this issue occurs, the logs and events in the system tell you NOTHING. And because of the nature of the issue, aka everything in the GUI drops to 5fps, it forces you to do a hard reboot. My system is a Framework 13, no modifications, no kernel parameters, STOCK default install.
1 Like
Good to know about the Firefox 136 with HW accel and/or using another browser. Thanks for that tip!
@inffy yeah I can see your point of view 
Howdy everyone!
Thanks for being patient with me. I’ve spent a bit of time looking into this and have some early findings I’d like to share in regards to system slowdowns occurring in KDE during video playback.
I was able to replicate the issue of KDE suddenly becoming slow under video playback. I was able to make this happen with Dragon Player and Haruna, as well as in Chromium-based browsers, but I was not able to replicate it in Firefox, mpv, or VLC. This slowdown only seems to occur with Adaptive Sync set to “Always” in display settings. My early educated guess at this point is that there’s something about these apps in particular that is causing the system’s frame rate to be brought down to match the frame rate of certain video sources. It does not appear to be caused by QT because VLC works fine, and it does not appear to be a libmpv related issue because mpv itself does not cause this behavior.
For now, I don’t seem to be able to replicate the behavior in a fully updated stock install of Fedora 41’s KDE spin with Adaptive Sync set to “Automatic”. If anybody has any more details about replicating this issue or conditions under which they see it happening, I’ll be keeping an eye on this thread.
1 Like
Can AMD address this issue already, it’s very annoying to have to disable PSR to resolve this issue :<
FYI - PSR-SU is now disabled by default while some things are being worked out.
This HW lock change may help you as well (although admittedly it was made for a bug with PSR on Ryzen AI).
Nice to know, thanks! Not sure if coincidence or not, but as I switched from Firefox to Brave browser (following @J_Frame hint in this thread), I have not experienced this issue again.