Fedora Account System
Red Hat Associate
Red Hat Customer
## Description The `amd-gpu-firmware` update from `20260810-1.fc44` to `20260910-1.fc44` ships a **lower** DMCUB microcode version for YELLOW_CARP (DCN 3.1.2) than the package it replaces: | Package | `yellow_carp_dmcub.bin` ucode_version | |------------------------------|---------------------------------------| | amd-gpu-firmware-20260309-1 | `0x04000047` | | amd-gpu-firmware-20260810-1 | `0x0400004C` (works) | | amd-gpu-firmware-20260910-1 | `0x0400004A` (**regression**) | Verified by decompressing the shipped blob and reading `ucode_version` at offset 0x10 of the common firmware header: # amd-gpu-firmware-20260910-1.fc44 (installed) 00000010 4a 00 00 04 10 97 03 00 00 01 00 00 1a fc f8 2a |J..............*| sha256: 5cdaaa2c159b0742d38cb655311550a5c4dfefe9bdf12c0fc02d8f14fce781a2 # amd-gpu-firmware-20260810-1.fc44 (previous) 00000010 4c 00 00 04 10 99 03 00 00 01 00 00 79 00 f3 aa |L...........y...| sha256: 3f871acbdb93e5c9aac03805abd597c59bd220388f3e37dc9ccc2cf21c884b6f The PSP refuses to authenticate the 0x0400004A image, DMUB never starts, and the eDP link to the internal panel fails to train. The machine boots completely (networking, gdm, and the GNOME Shell Wayland greeter all start normally) but the panel stays dark, so it presents to the user as a boot failure. ## Actual results amdgpu 0000:06:00.0: [drm] Loading DMUB firmware via PSP: version=0x0400004A amdgpu 0000:06:00.0: failed to load ucode DMCUB(0x3F) amdgpu 0000:06:00.0: psp gfx command LOAD_IP_FW(0x6) failed and response status is (0xFFFF0008) amdgpu 0000:06:00.0: [drm] Wait for DMUB auto-load failed: 3 amdgpu 0000:06:00.0: [drm] *ERROR* Error getting DMUB FW meta info: 4 amdgpu 0000:06:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data ... (repeats 126-231 times per boot) ... amdgpu 0000:06:00.0: [drm] enabling link 0 failed: 15 ## Expected results DMUB loads and the internal panel lights up, as with 20260810-1: amdgpu 0000:06:00.0: [drm] Loading DMUB firmware via PSP: version=0x0400004C amdgpu 0000:06:00.0: [drm] DMUB hardware initialized: version=0x0400004C (zero DMCUB errors, no link-enable failure) ## Steps to Reproduce 1. Rembrandt / Radeon 680M system (DCN 3.1.2, YELLOW_CARP) running amd-gpu-firmware-20260810-1.fc44. 2. `sudo dnf update` -> amd-gpu-firmware-20260910-1.fc44 installed, initramfs regenerated. 3. Reboot. Panel stays black; the system is otherwise up and reachable. ## Hardware - ASUSTeK ROG Zephyrus G15 GA503RS, BIOS GA503RS.317 (02/27/2024) - AMD Ryzen 9 6900HS with Radeon Graphics - iGPU: Rembrandt [Radeon 680M] [1002:1681] rev c7, subsystem [1043:13dd] (amdgpu) - dGPU: NVIDIA GA104M [RTX 3080 Mobile] [10de:249c] (nvidia, blacklisted nouveau/nova_core) - UEFI boot, Secure Boot disabled ## Additional info **This is not kernel-specific.** It reproduces purely from the firmware change; the same regression is reported on Arch and CachyOS across unrelated kernels: - https://bbs.archlinux.org/viewtopic.php?pid=2309459#p2309459 (independently reports the identical version pair: 20260910-1 = 0x0400004A broken, 20260810-2 = 0x0400004C working) - https://discuss.cachyos.org/t/regression-linux-firmware-amdgpu-20260910-1-dmcub-fails-to-load-on-amd-radeon-680m-rembrandt-causing-slow-boot-and-visual-glitches/35623 Other hardware reported affected in those threads: Radeon 9070 XT, 9060 XT, 7700S, and Raphael. Severity varies -- some users see only slow boot and visual glitches, others (as here) a completely dark panel. **The regression can be masked on the previously-installed kernel.** An older kernel whose initramfs predates the firmware update still carries the 0x0400004C blob and boots fine, which makes this look like a kernel regression rather than a firmware one. Regenerating that initramfs (`dracut -f`) breaks the older kernel too. **Workaround** (avoids downgrading the whole version-locked firmware package set, which would also revert amd-ucode-firmware/CPU microcode): sudo install -D -m 0644 yellow_carp_dmcub.bin.xz \ /lib/firmware/updates/amdgpu/yellow_carp_dmcub.bin.xz # from 20260810-1 sudo restorecon -Rv /lib/firmware/updates/amdgpu sudo dracut -f --regenerate-all **Suggested fix:** revert `yellow_carp_dmcub.bin` to the 0x0400004C build from 20260810, or rebase to a DMCUB release >= 0x0400004C.
Mario: is this a known issue? Seemingly caused by upstream commit ed94b3559
Confirming identical regression on a second OEM and APU model (MSI Thin A15 with Ryzen 5 7535HS / Radeon 660M): Hardware: - Model: MSI Thin A15 B7UCX - BIOS: E16RKAMS.10E - CPU: AMD Ryzen 5 7535HS with Radeon Graphics - iGPU: Rembrandt [Radeon 660M] [1002:1681] rev 0b, subsystem [1462:1437] - dGPU: NVIDIA GeForce RTX 2050 Mobile [10de:25ad] rev a1, subsystem [1462:1437] - Kernel: 7.2.5-200.fc44.x86_64 Symptoms: Immediately upon updating to amd-gpu-firmware-20260910-1.fc44 and rebooting, the internal eDP display remains completely black with no Plymouth splash and no GDM output. dmesg shows the exact same PSP rejection and DMCUB load failure: amdgpu 0000:05:00.0: [drm] Loading DMUB firmware via PSP: version=0x0400004A amdgpu 0000:05:00.0: [drm] *ERROR* Error getting DMUB FW meta info: 4 amdgpu 0000:05:00.0: failed to load ucode DMCUB(0x3F) amdgpu 0000:05:00.0: psp gfx command LOAD_IP_FW(0x6) failed and response status is (0xFFFF0008) amdgpu 0000:05:00.0: [drm] *ERROR* Error queueing DMUB command: status=2 Workaround verified: Copying yellow_carp_dmcub.bin.xz (version 0x0400004C, SHA256: 3f871acbdb93e5c9aac03805abd597c59bd220388f3e37dc9ccc2cf21c884b6f) from amd-gpu-firmware-20260810-1.fc44 back into /usr/lib/firmware/amdgpu/ and rebuilding initramfs with dracut completely restores display functionality on kernel 7.2.5-200.fc44.x86_64.
Sorry folks of the issue. But thanks for gathering all the details and bisecting down to the specific commit that caused it. I've sent up the revert: https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1241 We'll investigate internally what went wrong with this one.
We'll land this in Fedora with the next tagged upstream release, in the meantime it's likely easiest for the users hitting this to downgrade.
*** Bug 2533250 has been marked as a duplicate of this bug. ***
*** Bug 2533632 has been marked as a duplicate of this bug. ***
*** Bug 2533325 has been marked as a duplicate of this bug. ***
*** Bug 2533809 has been marked as a duplicate of this bug. ***
(In reply to Peter Robinson from comment #4) > We'll land this in Fedora with the next tagged upstream release, in the > meantime it's likely easiest for the users hitting this to downgrade. Sorry for the advocacy, however may I ask you to reconsider this decision and push a (dummy/revert) upgrade out of schedule ? Diagnosing then downgrading a broken system is far from easy unless you already know how to read logs and manually manage firmware. This is not a regular minor inconvenience to the average user, and with automatic upgrades the more you wait the more users will upgrade to the broken firmware.
We are working with various vendors to ensure all the fixes are in place, and with upstream, ultimately I don't want to make the problem worse, and we have 1000s of firmwares in this package that affect different users in different ways.
FEDORA-2026-91cb8c4497 (linux-firmware-20260916-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-91cb8c4497
FEDORA-2026-e671ef50bd (linux-firmware-20260916-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e671ef50bd
FEDORA-2026-6568e9177a (linux-firmware-20260916-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6568e9177a
FEDORA-2026-e671ef50bd has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e671ef50bd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e671ef50bd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2536023 has been marked as a duplicate of this bug. ***
FEDORA-2026-91cb8c4497 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-91cb8c4497` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-91cb8c4497 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-6568e9177a has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-6568e9177a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-6568e9177a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-e671ef50bd (linux-firmware-20260916-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-91cb8c4497 (linux-firmware-20260916-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Problem still persists for Ryzen 5 7535hs [Radeon 660M] on Leneovo ThinkBook
(In reply to Vangreen from comment #21) > Problem still persists for Ryzen 5 7535hs [Radeon 660M] on Leneovo ThinkBook Did you regenerate the initrd?
Hello I was not very patient and I switched to Ubuntu 26.04.1. Is this bug fixed on Fedora KDE Plasma Edition 44 ? Regards YE
FEDORA-2026-6568e9177a (linux-firmware-20260916-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Confirming the fix on a fourth OEM/model: Lenovo ThinkPad E16 Gen 2 (Ryzen 7 7735HS, Radeon 680M, 1002:1681 rev 0a), Fedora 43 KDE, kernel 7.2.5-100.fc43. With linux-firmware-20260916-1.fc43 the DMUB loads ("DMUB hardware initialized: version=0x0400004C"), zero DMCUB errors, and both external displays over USB-C DP Alt Mode are detected again. The shipped yellow_carp_dmcub.bin is byte-identical (sha256 4bcb91d58ba727684845b02a9cdd32f37cb5a9f71bd4b93d4e678094465cda47) to the one from 20260810-1. Re comment #21: on my system the fix only takes effect after the initramfs is regenerated (sudo dracut -f --regenerate-all) and a reboot - the package upgrade alone left the old blob in the initrd of the running kernel. Re comment #23: yes, 20260916-1 reached stable for F43/F44/F45 (comments #19, #20, #24).
I experienced the same DMCUB/DMUB issue on a system with a Radeon 680M (YELLOW_CARP / Rembrandt). My system was running: Fedora 44 Kernel: 7.2.5-200.fc44.x86_64 GPU: Radeon 680M (1002:1681) amd-gpu-firmware-20260916-1.fc44 Even though the installed firmware package was already the fixed 20260916-1 version, dmesg still showed: amdgpu 0000:04:00.0: [drm] Loading DMUB firmware via PSP: version=0x0400004A amdgpu 0000:04:00.0: [drm] *ERROR* Error getting DMUB FW meta info: 4 amdgpu 0000:04:00.0: failed to load ucode DMCUB(0x3F) amdgpu 0000:04:00.0: [drm] Wait for DMUB auto-load failed: 3 amdgpu 0000:04:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data The installed firmware file in /usr/lib/firmware/amdgpu/yellow_carp_dmcub.bin.xz was already 0x0400004C, but the initramfs still contained an older copy of yellow_carp_dmcub.bin.xz. I regenerated all initramfs images with: dracut --regenerate-all --force After rebooting, the system loaded the correct DMCUB firmware (0x0400004C) and the DMCUB/HDMI errors were gone. HDMI output then worked normally. So, in my case, the problem persisted because the initramfs was still containing the older 0x0400004A firmware even after the fixed linux-firmware package had been installed.