The problem started immediately after I installed system updates on the evening of September 14, 2026. Before that update, the display and HDMI-connected TV worked normally. After restarting, the system was using kernel 7.2.5 and the display problems appeared.
Symptoms with kernel 7.2.5:
The built-in screen was stuck at maximum brightness.
The built-in screen flickered slightly.
The screen did not turn off completely when the laptop entered sleep.
The HDMI-connected TV showed no picture.
The AMDGPU DMCUB error appeared repeatedly.
Booting kernel 7.2.4 fixes the problem; the built-in display and HDMI-connected TV work normally.
Thanks. I’m currently booting kernel 7.2.4, which restores the built-in display and HDMI output. Kernel 7.2.5 produces the DMCUB errors and the display problems described in my post. I’ll wait for a fixed kernel or other recommended update.
→ this is for f44! Change the command correspondingly for F43 and for other kernel versions! dracut is capable to auto-fill with double-tab, so you can just do double-tab after …initramfs and choose the correct possibility, and the same for the next parameter (which is then only the kernel parameter).
The issue is known and will be solved in the next linux-firmware update. Unfortunately, that might take a few days.
So expect you need to re-do this with 7.2.6 (which is already in testing). Keep in mind that your system will auto-update the firmware again, so when doing the same for 7.2.6, you need to start again with downgrading firmware.
I’m a novice (started using Linux earlier this year) and would prefer to wait for the corrected firmware update rather than manually downgrade firmware. Could someone confirm when the fix is available and which update contains it?
The maintainer wants to bring this to Fedora with the next upstream release, maybe it is already added upstream, maybe he does add it manually for Fedora. The result for you is the same. But I cannot give you a promise when this will be.
It will be an update of amd-gpu-firmware (part of linux-firmware). However, the update will not become “active” before the initramfs is rebuild with the new update. So either when the next kernel is installed (so the next kernel after the firmware update has been installed) or when you manually rebuild initramfs.
Testing might be possible already in a few hours ! (the rpms in koji can already be tested for those who know about it)
But as I said before: the update itself does not rebuild the initramfs, but rebuilding the initramfs is necessary to get the fixed firmware used during your boot. Once this update is available and installed on your system, the solution is either the dracut command I suggested above (adjusted correspondingly to your condition), or wait for the next kernel update. I expect just re-installing a kernel with dnf might also do the trick but I didn’t test it yet, as some might feel safer with that compared to working with dracut. I can hopefully invest some time to update this post on Friday with a more precise and tested workaround to get the update applied where we need it in a user-friendly way. With some luck, the update is then already approaching stable.
Also, there is already a report that this update fixes the 680M issue
Update: I wanted to find out if it works before I go to bed I already tested the update, and it fixes the issue on my 680M machine
It’s done: the firmware update with the fixed is available in stable, and many people already confirmed it solves the issue. If you experience this issue, please do all of the following in the given order, and if you customized much on your system, keep in mind the following is intended for a default Fedora (but the following commands will not be impacted if you just installed more software from the Fedora repositories or so, and also not by any customizations of your user account, which is customizations that do not need sudo or admin password):
boot the most recent kernel that works fine (should be 7.2.4 for everybody who does at least weekly updates)
sudo dnf update --refresh *-firmware
sudo dnf reinstall kernel*
Reboot, and then boot the most recent kernel, which is 7.2.5 or in a few days 7.2.6: the most recent kernel should work now! And future kernels too.
→ Silverblue/Kinoite users must translate the dnf to rpm-ostree commands, which I assume they are used to: maybe someone can post the commands below in the next days. But since 7.2.6 is already on its way, that might solve the issue anyway soon by the usual updates as well, as that should then already use automatically the new firmware that is already in stable before 7.2.6.
Expert users who know of dracut etc can use of course the means they are used to: this is a user-friendly way that should avoid that the user needs to adjust anything that can break things (dracut commands etc) or that users feel unsafe
Post here if it doesn’t work etc. If everything works but it does not solve your problem, please add the output of lspci | grep AMDandcat /proc/sys/kernel/tainted when posting.
Because there had been already several, partially dangerous, ideas of how to mitigate in some of the topics about this, I select this as solution so that users are led here before they attempt one of them: the OP is free to change this choice if they disagree!
@vette95 This topic is about amd, not nvidia & intel. Please stay on topic. Your bug report is unrelated.
You can open a new topic, but keep in mind that using different channels with the sole purpose to urge maintainers to process one’s own problem is seldomly leading to the desired outcome, as it misses a lot of implications and does itself not add value.
I just wanted to boot the 7.2.4 kernel, but in my GRUB are only 7.2.5, 7.1.13 and 7.1.12 shown. Can I try step 2 to 4 with the 7.1.13 version of the kernel?
Yes, but at this time, we have already 7.2.6. So you can actually just do dnf update --refresh. Then you should have 7.2.6 and the new firmware. If that 7.2.6 would behave as your current 7.2.5 (so black screen etc), it would be nice to get a short feedback about it, but we have a consensus that it is unlikely that 7.2.6 would not work in this context*. But even in that case, you could do just step 3 (from 7.1.13) and then everything should be fine, but as I said, we expect the dnf update --refresh would suffice at this time.
By the way, you might consider to more often do updates on your system, also for security reasons.
* we assume when creating the new initramfs, the 7.2.6 scripts would already use the new firmware, even if the new firmware itself is just updated during the same update process with the kernel (the reason is the so-called %posttrans that is used for creating the new initramfs).
Not sure what you mean, there is no --help package. dnf offers you the --help parameter if you had a typo or so in your command. dnf update --refresh should work off the cuff.
Update: don’t forget the sudo if applicable So on default systems, it’s now sudo dnf update --refresh . But the system would tell that if forgotten, and not refer to --help.
That you have no 7.2.4 but jumped from 7.1.X to 7.2.5 suggests you didn’t do kernel updates for a while Therefore my suggestion
Update: on f44, it should be even 7.2.7. that is in the next update
I already tested the update, and it fixes the issue on my 680M machine 
