Bug 201497

The revert was only supposed to apply to 4.18 and below, there should be a series of patches that fixes this for 4.19.

Please post an updated dmesg log for your 4.19 kernel.

Created attachment 279133 [details]
4.19 dmesg

dmesg attached

Any progress on this issue?

Created attachment 280261 [details]
4.20 didn't fix this

Still an issue on 4.20

Created attachment 280619 [details]
4.20 log

I'm hitting the same issue with one of my monitors (ASUS VG248QE, G-Sync modded). I tried extracting EDID from kernel 4.18 and forcing it with drm.edid_firmware as you can see in the log, but that doesn't seem to do anything. My GPU is AMD RX 580.

Created attachment 280701 [details]
5.0-rc3 drm.debug=0x4

This is still an issue on 5.0-rc3.

Same here, RX580 and an ASUS PG278Q monitor, also with G-Sync support.
A different DisplayPort monitor (without G-Sync) worked perfectly.

I've noticed someone else with the same monitor having this issue over on the freedesktop bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=108806

Interestingly, in more recent kernels, the affected monitor appears to flash rapidly. I still see the EDID read fail in this case. I'll try and grab a dmesg of this at some point.

Created attachment 280777 [details]
dmesg, amd-staging-drm-next-git (d0333a48e54fdcfdae5e378acd898a680967e939)

Same here RX480 and ASUS PG278Q also.
My archlinux is stuck at 4.18.16 since october 2018.
Is there a workaround or someone that is looking at this bug ?
It's been broken from 4.19 up to 5.0.

Is this going to get fixed?

Been struggling with this issue for quite some time
Is there any progress made?

ASUS ROG Swift PG278Q
R9 380X
5.4.0-rc1linux-5.4-rc1

[    2.776432] [drm:dc_link_detect [amdgpu]] *ERROR* No EDID read.

I wonder if it's not a bad EDID from the monitor.
Anyway, that's a regression from 4.18.

Same here with Acer XB240H and AMD Vega 56: 
https://bugzilla.kernel.org/show_bug.cgi?id=205987

All Kernels >4.15 have this

*** Bug 205987 has been marked as a duplicate of this bug. ***

I managed to force the kernel to use the EDID extracted via get-edid on kernel 4.18 thanks to https://bugzilla.kernel.org/show_bug.cgi?id=199799#c4 . The trick was to add video=DP-4:e to the kernel parameters, so in my case the complete addition looks like:

drm.edid_firmware=DP-4:edid/ASUS_VG248QE.bin video=DP-4:e

ASUS_VG248QE.bin was extracted with get-edid on kernel 4.18 and placed in /usr/lib/firmware/edid/. With this in place, I can use my monitor fine on the latest kernel (5.5.5).

Without this, I have the exact same issue on 5.5.5.

I have traced my personal version of this bug down to my Acer monitor and Logitech gamepad. Both are detected, but only the monitor works. The error spits out toward the end of dmesg about ten times in a row, twice. Thank you.

Created attachment 292811 [details]
5.8 dmesg RX 580

I believe am hitting the same issue.

I have a DP monitor ACER XB270HAbprz and it is stuck in 640x480 on my RX 580.

This is on Linux 5.8.

On monitor replug this relevant line pops up:
[drm:dc_link_detect_helper [amdgpu]] *ERROR* No EDID read.

This same monitor with the same cable works great on GTX 970 and GTX 1080 Ti under Nvidia 455.23.04.

A short update:
In the meantime I am adding the modeline for my monitor manualy.
The automated solution is a 10-monitor.conf like in this thread:
https://archived.forum.manjaro.org/t/stuck-at-low-display-resolution/115976
This works until Kernel 5.8. With Kernel >= 5.9 my monitor doesn't accept the modeline anymore.
Since this problem has been reported 2 years ago and nothing happened, I am wondering if it will ever be fixed. Let me know how I can follow up/contribute to fix this.

hi!

I had this issue for a longtime. And then, I recently got a new hdmi cable and never had the error since!

(or at least symptoms of it: the pc having trouble to enable the display after a warm reboot, and having to do a 'really' cold reboot by turning the pc off for a few minutes to get it back.  I haven't been checking the logs extensively since it now works...)

Hi, I'm also running into this issue, using an RX Vega 64 with an Asus ROG display. Let me know if there's any logs or testing that I can do to assist.

The more I think about it,
the more it seems to be related only to this monitor.

I think the 4.19 kernel closed a bug and is rejectiting the EDID reported by this screen.

If someone could validate this EDID is correct, it'll be of great help.

@Sebastien that could well be the case. The screen works fine under windows, but it could be that they are working around bad EDID data?

Is there any way I can validate if the EDID is bad?

Update:
We are now at Kernel 5.11 and this problem is still not fixed. I am stuck at 5.8 + manually entering the EDID on startup.
When 5.8 gets too outdated for me, I will buy a new monitor. I guess we cannot expect any fix after almost 3 years.

Issue is back in 5.17.9 (and 8), AMD 5600G, Mesa 22.2~git2205170600.fffafa~oibaf~f, so its 4 years now?

I still see this error in 6.2.10-arch1-1. It happens for displays connected through a USB-C hub:

[    5.230549] EDID block 0 is all zeroes
[    5.230552] [drm:dc_link_add_remote_sink [amdgpu]] *ERROR* Bad EDID, status3!

A suspend / resume after system boots to login screen solves the issue. But it comes back sometimes when display is suspended due to idle or other system suspend/resume cycles.

My display is connected via HDMI and on 6.2.10 mainline this error is coming up all 2 to 3 minutes in the logs. A relation to a display suspend is quite right in my eyes, because it stops when the display is woken up and starts again on display suspend.

This makes my docked laptop almost unusable :( Once it suspends the displays, there's no coming back. I'd need to undock, and hope it recovers. After undocking, re-docking the USB-C hub does not help, external displays mostly dont come back. Needs reboot :(

I wonder if there's a way to change severity/importance of this bug, I'm worried that nobody looks at it as it's tagged 4.19 and 5.x while it exists in the latest version of kernel. This effects usability big time.

I share that concern. Can the OP create a new report with a recent kernel and updated logs, maybe with a link to this report? That would be wonderful!

By the way, my last comment, that the issue stops when the display is woken up is wrong. Sometimes one display suspend is enough that the issue will repeat in the logs, even if the display is "on" after that all the time. But this is rather sporadic, sometimes the errors stop, sometimes they continue.