Def related, the 2.29 firmware is the cause of it. Was able to revert back to 2.26 and my computer’s working fine now (actually writing this from it). Reinstalled 2.29 out of curiosity and the half black screen came back immediately. Also found this thread on the Mint forums of people having the exact same problem I did: https://forums.linuxmint.com/viewtopic.php?t=472692. I know AI is sort of a big no-no nowadays (I’m new to Linux after basically 30 years of using Windows so I appreciate the help) but it led me to the Mint forum and this is what it had to say after it helped me troubleshoot. Hopefully you, or someone else, understands it better than I do:
Now I’ve got real evidence trail, not just correlation. There’s an actual bug filed for this, and it points at a specific file.
What DMCUB actually is. It’s not just a data file the driver reads once — it’s a small, complete program that gets loaded onto a dedicated microcontroller physically built into your GPU’s display engine. Once running, that microcontroller handles the real-time, latency-sensitive parts of driving your monitor: negotiating power-state transitions, managing display link training, and other timing-critical handshakes that would be too slow to manage from regular OS-level driver code. The kernel’s amdgpu
driver loads this program onto the chip at boot and then talks to it via a structured command protocol — it’s a relationship between two separate pieces of code, not just a driver reading a config file.
The specific file involved. Your 6800XT belongs to the “Sienna Cichlid” GPU family, and its DMCUB firmware ships as a literal file: amdgpu/sienna_cichlid_dmcub.bin. Upstream’s own firmware repository shows a batch commit updating DMCUB firmware across several chip families at once — covering DCN401, DCN36, DCN35, DCN351, Beige Goby, Dimgrey Cavefish, and Sienna Cichlid together in one firmware release. The listed fixes in that release are specifically IPS entry and Replay-related fixes for the DCN35/DCN351/DCN36 chips, and LSDMA fixes for DCN401 — Sienna Cichlid isn’t called out with a fix of its own; it just rode along in the same firmware refresh cycle as the primary chips actually being fixed. Ubuntu + 2
Why that produces your exact symptom. That’s a common way regressions slip through — the chips with named fixes get focused testing, while the ones just carried along get a new firmware build without the same scrutiny. Since DMCUB firmware isn’t a monolithic “works or doesn’t” blob — it manages several sequential stages (link training, then power-state setup, then ongoing timing management) — a bug introduced in one of those stages can let earlier stages still succeed before things fall apart. That lines up with what you saw: enough of the handshake completes to get a partial, garbled image up, then the whole thing collapses once the broken stage is reached.
The refresh-rate detail backs this up. One report on the same Mint forums thread found that dropping the display from 144Hz to 60Hz let it run for a few minutes longer before it still eventually turned black with corruption — consistent with a flaw in a repeating handshake step: at 144Hz that step executes far more often per second than at 60Hz, so a marginal/racy bug gets triggered sooner. Linux Mint Forums
And it’s not isolated to Navi 21. In the same .29 release, a completely different chip generation — DCN314/Phoenix (a laptop APU family) — got its own separate DMCUB-related regression, involving invalid memory accesses during eDP power transitions. Two unrelated GPU families both breaking on DMCUB-adjacent paths in the same firmware build points to a quality problem with that specific release batch, not something particular to your card or setup. Ubuntu
One honest caveat: this is the most coherent explanation the available evidence supports — the filed bug, the firmware commit history, and DMCUB’s known architecture — but neither AMD nor Canonical has published a formal root-cause writeup yet, since the bug is still open and recent. If one lands later, the exact internal detail might refine this, but the shape of it (bundled firmware update → untested handshake regression → partial-then-total display failure) is unlikely to change.