I am running a FBS (f****** big screen) Samsung Odysseys Arc 55inch on a AMD Ryzen 9900X via HDMI.
OS is Debian sid with 6.11.9 kernel and the latest 2024-09-09 amdgpu firmware.
The problem is that everytime the monitor goes into powersave, I do get this:
[33498.371547] EDID block 0 (tag 0x00) checksum is invalid, remainder is 40
[33498.371556] amdgpu 0000:17:00.0: [drm] *ERROR* EDID checksum invalid.
And after that, the screen wakes up at 640x480 which looks hilarious on such a big screen. I cannot switch to any other resolution, and even a reboot does not solve that problem. Worse, I cannot even enter BIOS because the BIOS on my Asrock B670 board cannot function at 640x480 LOL
The only way to recover this situation is to either fully switch off the computer or unplug and replug the HDMI cable.
So obviously this situation is bad. I tried opening support cases with both Samsung and AMD, while Samsung does not care at all (they basically ghostlighted me, which is some of the worst support experiences I have had in a while) AMD has not even responded.
So I do not know where the problem lies exactly. Is it driver related? I could verify that the problem also exists on a Nikear laptop also with AMD Ryzen 885xH (same kernel and firmware).
My guess is that it probably is AMD GPU related, but how to fix this?
Apart from that, the screen for f***** 2000 USD is just one week old. I am very tempted after Samsung’s behaviour to just dump f***** 80 pounds of screen back to the shop where I bought it from. Companies that gaslight customers should feel pain!!!
Maybe someone here has some idea what I can do (apart from disabling power save mode which is not a real solution for a screen that power hungry).
This is definitely the amdgpu driver trashing the EDID then attempting to reuse it. You might be able to save the EDID from a known-good run then switch to a virtual console (Ctrl-Alt-F2 or Ctrl-Alt-F3) to reload and override the received data with something like cat correct-edid.bin | sudo tee /sys/kernel/debug/dri/0/HDMI-A-2/edid_override (from Archi Wiki on Kernel Modesetting → forcing modes and EDID) replacing the 0 and HDMI-A-2 with whichever dri device number and connector your screen is plugged in to.
Maybe you could try ignoring the supplied EDID throughout a boot by saving a copy to /lib/firmware with find /sys/devices/pci*/ -name edid and cp or cat to a save the file. Then following the instructions in the 6.11 Kernel commandline documentation for drm.edid_firmware. The directory /lib/firmware gets picked up and put into your initramfs so it’s available at boot time. Then the GNU Grub commandline for Debian is in /etc/default/grub and you’ll need to run sudo grub-update after adding the drm.edid_firmware=... bit inside the quotes on the line GRUB_CMDLINE_LINUX_DEFAULT="..."
You might turn off powersaving and power down the screen instead of letting it sleep. Does the problem still happen then?
I did actually try to put the EDID into the initramfs, it wasnt as simple as you described, but I got it done via writing a hook and placing it in the appropriate /etc/innitramfs*hooks.d directory. I did verify the edid gets placed in the initramfs, but next problem was my system does not use grub, but the boot strings somehow are in the EFIVARS. I did get solved as well, and the kernel booted with drm.edid_firmware=… set. Problem did still occur with that setting.
So, it seems this is indeed an issue with the AMDGPU driver. How to go about to get this solved? Honestly, I am paying quite a bit for these AMD Cpus (do own multiple), so I would actually expect AMD to get such basic functionality right and actually provide support.
AMD did get back to me via their official support channel, asking me about my power supply, installed fan and RAM, as well as to provide them with a dxdiag something.
I wrote them back
$ dxdiag
bash: dxdiag: command not found
Lets see what they make of that (I did mention multiple times in my initial support request that it is Linux, provided Kernel and firmware versions, and yet they still gave me troubleshooting instructions for WinDumb).
To update all on this issue, I bought a 8K DisplayPort cable and it looks like with DisplayPort this issue does not arise.
So I will continue to work through this with AMD through their support channel, and see how far I get. Time they treat Windows and Linux users equally with regards to support. Long overdue.