I tried using theamdgpu.dc=0 and amdgpu.aspm=0 kernel parameters together, but it didn’t work. I also tried using amdgpu.aspm=0 on its own, and that didn’t work either.
After further research and debugging, I also think that this is a hardware or firmware issue, as @dalto suggested.
Specifically, the problem stems from a hardware-to-firmware communication failure known as a GOP (Graphics Output Protocol) initialization failure during a cold boot. There are two primary reasons for this:
-
Monitor Handshake Delay: The monitor’s wake-up time is too slow, causing it to miss the extremely brief initialization window of a cold boot.
-
Graphics Card VBIOS Issues: Some graphics cards cannot communicate at the pre-boot level without specific instructions. While this can sometimes be fixed with a VBIOS update.
For my Graphics Card I cannot find a newer version of VBIOS from my manufacturer. Furthermore, I have read that updating a VBIOS is risky because there is often no fallback utility if an error occurs—unlike my motherboard BIOS, which has a built-in recovery feature.
Since I don’t have another monitor to test with, I think I’ll leave it at this.
After two days of debugging, I’ve decided to stop here. I will just continue using my invisible GRUB menu to boot into both operating systems.
Thank you, everyone, for your help!
Fixed! The GOP Initialization Failure. The root cause was my UPS setup; both my monitor and PC are connected to it. I was waiting 4–5 seconds after turning on the UPS to boot my PC, thinking I should let the UPS “fully boot” first. This allowed the monitor to power on completely before the PC, causing a handshake issue. I realized this when I tried turning the PC on just 1–2 seconds after the UPS, and the error disappeared.