When I upgraded my BIOS to 4.2, I ran into a screen flashing problem. The screen would look fine but after anywhere from 5-30 seconds, at random intervals (it appeared), it would flash black. It was quite annoying. Furthermore, logging in at the GUI login screen was really difficult because the flashing was especially active then. At times, I would simply type my password and hope I did it correctly because I wasn’t getting any usable feedback.
I’m using KDE, btw.
The AI told me to add the following to my kernel command line: grubby --update-kernel=ALL --args=“amdgpu.psr=0”
It looks to have fixed the issue. FWIW, the AI said:
Why this started happening now
The sequence matters:
You adjusted power/idle behavior
KDE + PowerDevil + KWin start interacting more with panel idle states
BIOS 4.02 updated panel / SMU firmware
Panel now advertises PSR capabilities differently
Timing margins change
KWin on Wayland (or even X11) hits PSR edge cases
Screen idles → PSR enters
GPU wakes → bad transition
Result: brief black frame
This is very typical on AMD laptops right after firmware updates.
Why it looked random
PSR triggers when:
Framebuffer is static
No damage events
Backlight timing lines up just wrong
Hence:
5 seconds sometimes
30 seconds other times
Often worse when “nothing is happening”
That randomness is a hallmark PSR failure mode.
Which Linux distro are you using? Fedora
Which release version? 41 and 42
Which kernel are you using? 6.17.10-100.fc41.x86_64, and 6.17.13-200.fc42.x86_64
Which BIOS version are you using? 4.2
Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7940HS)
However, I am going to try with the less agressive option:
amdgpu.dcdebugmask=0x10
Allegedly, the second one disables PSR2 but not PSR1.
I also am not sure that this is entirely a Framework issue, I think its moreso an issue in the kernel. But, the bugs for this were closed quite some time ago. I am not 100% sure on what to file this under as there are a ton of projects - but plan to file a bug when I get some free time.
Thanks for the 0x410 suggestion. That seems to have taken care of it!
amdgpu.psr=0 is not recognized by the kernel at all, on this machine, and it will print a message in dmesg to that effect. So the only thing I needed to add was amdgpu.dcde
bugmask=0x410 .
Which is actually a little disconcerting, if I’m being honest.
@Michael_Schwager does this problem occur only after a suspend-to-disk (AKA “hibernate”), then a resume? That’s the behavior I’m seeing, at least. If that is different from what you’re seeing, then let me know and I’ll report this elsewhere.
Fresh boot or reboot –> display is fine.
Suspend to disk –> laptop powers off; ok.
Power on –> laptop resumes from disk.
Unlock screensaver –> after about 15s, the screen turns black.
The display is black unless something causes the display to change, e.g. a mouse movement; running glxgears is a good temporary workaround to keep the display working while I try to use it.
For me, amdgpu.dcdebugmask=0x400 is the necessary kernel parameter to work around the bug permanently. amdgpu.dcdebugmask=0x410 works too, but that’s because the value is a bitmask. 0x410 == 0x400 + 0x10, and 0x400 is the one that matters.
I don’t know if this is a driver bug or a firmware bug. I had unrelated issues with suspend-to-disk prior to some upgrades, so I don’t have a previously working state to try.
@knipp30 on the possibility that this is a driver bug, you can report it by filing a bug report here:
This particular issue is similar to an earlier issue:
…but not quite the same. Common aspects are:
Affected hardware (framework 16).
amdgpu.dcdebugmask=0x400as a workaround.
Disabling compositing in xfce makes the problem not manifest.
Differences are:
The earlier issue did not require a suspend-to-disk to manifest.
The earlier issue make the display seem to “freeze”, not turn black.
Also, I’ve seen the problem go away a couple times when I leave the laptop running and come back later (maybe 30 minutes later–I haven’t been keeping track).
Also also, a suspend-to-idle (and then resume) does seem to make the problem go away immediately.
I tested many older kernels today, going back as far as 6.12; these were all self-compiled, using substantially the same config (make olddefconfig using my standard set of defaults for doing bisects).
Initially, there seemed to be a two distinct behaviors:
Screen flickering rapidly (5 Hz or something like that) except when being updated by e.g. mouse movement.
Screen black except when being updated.
With further testing, I now think these two behaviors are different manifestations of the same problem. The same kernel reversion may show a different behavior on a different boot.
In all cases, though, the problem only started after a resume from a suspend-to-disk
I’m fairly confident by now that the problem is indeed due to the BIOS update. Unfortunately, Framework does not allow the BIOS to be rolled back to 3.3, so I cannot confirm.
This is exactly what I was complaining about here: