I have once solved AMDGPU not waking up from hibernation just by compiling the driver into the kernel.
The AMDGPU modules weren't loading somehow and even after spending some time, I couldn't fully debug the issue, as I'm missing an USB debug cable, the hardware didn't had Intel AMT serial over LAN and it lacked a real serial port.
You can try netconsole, a debug console over UDP/IP, implemented within the Linux kernel at a very low-level. It can keep sending logs over the network even if a kernel panic has occurred. If both netconsole and the Ethernet driver is built into the kernel, it's almost a serial-port substitute, a really handy debug tool for all kinds of black-screen-of-death issues. To debug an issue like that, I prefer connecting my workstation directly to the target (without routers and switches) and assign a static IP address on both ends. Netconsole for kernel space, SSH for userspace.
The only thing it cannot do is collecting logs from the very earlyboot process. "The AMDGPU modules weren't loading" may or may not be an earlyboot problem, just try and see if you are lucky enough.
https://www.kernel.org/doc/html/latest/networking/netconsole...
IIRC it wasn't sending logs to my target machine at this boot stage, and I couldn't even get a flash of a kernel panic message to record it in slow motion on my phone. That's why I think only an USB debugger cable could help in this case.
And to be fair, I'm just guessing the modules weren't loading, after they got compiled in, everything worked like a charm. Didn't debug it further, as this happened in the beginning of the pandemic and finding an USB cable not shipping from China, with reasonable costs, was impossible.
I see.
> And to be fair, I'm just guessing the modules weren't loading, after they got compiled in, everything worked like a charm. Didn't debug it further
To be honest, I'm also guilty of WorksForMe-ism (adopting a workaround instead of debugging the real issue and call it a day, sometimes without even bother to publish the workaround)... ;)