CPU: Intel Coffee Lake Graphic:Intel [8086:3e92] Kernel: 4.14.0-997 http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2017-09-30/ Monitor: asus PA238Q/Dell P2415Qb Only can reproduce the issue with asus PA238Q.
Created attachment 134901 [details] kern.log and Xorg.0.log Test Result: 1. asus PA238Q 4.13.0-997: Pass 4.13.0-997 + i915.alpha_support=1: Failed 4.14.0-997: Failed 2. dell P2415Qb 4.13.0-997: Pass 4.14.0-997: Pass log_1018.tar.gz ├── asus_pa238q │ ├── 4.13.0-997 │ │ ├── kern.log │ │ └── Xorg.0.log │ ├── 4.13.0-997-i915_alpha_support │ │ ├── kern.log │ │ └── Xorg.0.log │ └── 4.14.0-997 │ ├── kern.log │ └── Xorg.0.log ├── dell_p2415qb │ ├── 4.13.0-997 │ │ ├── kern.log │ │ └── Xorg.0.log │ └── 4.14.0-997 │ ├── kern.log │ └── Xorg.0.log ├── dmidecode.log ├── lspci-nn.log
log_1018.tar.gz /asus_pa238q/4.14.0-997/Oct 18 15:31:01 u-OptiPlex-5060 kernel: [2.818759] [drm] Initialized i915 1.6.0 20170929 for 0000:00:02.0 on minor 0 [3.241622] i915 0000:00:02.0: HDMI-A-1: EDID is invalid: [3.725350] [drm] Cannot find any crtc or sizes [4.179233] [drm] Cannot find any crtc or sizes
Got one MB with HDMI port. The issue can be reproduced when connected with asus HDMI monitor directly without HDMI to DP adapter.
Could you please boot 4.14 again with drm.debug=0x1e and grab dmesg output. Thanks in advance.
Created attachment 136047 [details] dmesg (drm.debug=0x1e) dmesg (drm.debug=0x1e) Kernel: 4.14.0-997 http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2017-12-03/
There have been a few DDC fixes recently: 6481d5ed076e ("drm/i915: Disable GMBUS clock gating around GMBUS transfers on gen9+") cfb926e148e9 ("drm/i915: Try EDID bitbanging on HDMI after failed read") Please retest with the latest drm-tip: git://anongit.freedesktop.org/drm-tip drm-tip
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Created attachment 138414 [details] kern.log (drm.debug=0x14) Still can reproduce the issue with kernel-drm-tip-2018-03-29. http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2018-03-29/ kernel: [1.340931] [drm:intel_hdmi_detect [i915]] [CONNECTOR:71:HDMI-A-1] kernel: [1.390957] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging kernel: [3.570781] [drm:intel_hdmi_detect [i915]] [CONNECTOR:82:HDMI-A-2] kernel: [3.571559] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging kernel: [3.581936] [drm:intel_hdmi_detect [i915]] [CONNECTOR:90:HDMI-A-3] kernel: [3.582754] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging
The EDID doesn't look too badly corrupted. Comparing with https://github.com/linuxhw/EDID/blob/master/Digital/Ancor%20Communications/ACI23B1/1BEB6E3B3176 (which seems to be more or less the same monitor) I see that you have a slightly different blue y coordinate. Your blue y coordinate does look surprisingly small to me, so I have to wonder if it's gotten corrupted somehow. The other differences seem to be that yours doesn't specify the interface type (the other says DVI), slight differences in the est and std timings listed, and you have one extension block whereas the other one has zero. Most of this could be explained by the other person capturing the EDID from the DVI input of the monitor instead of the HDMI input. Have you tested the other inputs?
(In reply to Ville Syrjala from comment #9) > The EDID doesn't look too badly corrupted. Comparing with > https://github.com/linuxhw/EDID/blob/master/Digital/Ancor%20Communications/ > ACI23B1/1BEB6E3B3176 (which seems to be more or less the same monitor) I see > that you have a slightly different blue y coordinate. Your blue y coordinate > does look surprisingly small to me, so I have to wonder if it's gotten > corrupted somehow. In fact if I fix the blue y coordinate from 0x00 to 0x11 (to match the other EDID) the checksum becomes correct. So it does look like the EDID in your display has become slightly corrupted somehow. Would be interesting to see if the same EDID corruption is present on DVI and VGA inputs.
Any updates here from questions to Ville?
The monitor, asus PA238Q, supports DP, HDMI, DVI, and D-sub. But, My machine only supports two interfaces, DP and HDMI. There is no issue when connecting to the minotor with DP. The issue only occurs when using HDMI.
(In reply to Ethan Hsieh from comment #12) > The monitor, asus PA238Q, supports DP, HDMI, DVI, and D-sub. > But, My machine only supports two interfaces, DP and HDMI. > There is no issue when connecting to the minotor with DP. > The issue only occurs when using HDMI. You can convert from HDMI to DVI with a simple passive adapter/cable.
Created attachment 139084 [details] kern.log (drm.debug=0x14, Dell U2311Hb)
Created attachment 139085 [details] kern.log (drm.debug=0x14, asus PA238Q)
Hi Ville Still can reproduce the issue with asus PA238Q and DVI port. Please refer to comment#15 for detailed log. Dell U2311Hb works well. Please refer to comment#14 for detailed log. --- asus PA238Q DVI port <--> DVI to HDMI adapter <--> PC Dell U2311Hb DVI port <--> DVI to HDMI adapter <--> PC Kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2018-04-19/
(In reply to Ethan Hsieh from comment #16) > Hi Ville > > Still can reproduce the issue with asus PA238Q and DVI port. > Please refer to comment#15 for detailed log. Hmm. Yeah, looks like the DVI EDID is corrupted in the exact same way. We've not had reports of other corrupted EDIDs on these display so I'm leaning towards this being just some random EDID corruption in your particular display. You would either need to fix the EDID in the display via i2c (often there's some kind of service menu available by which you can toggle write protection of the EEPROM) via i2c. Or you need to use the firmware edid loader to override the EDID, which would involve something like putting the fixed EDID into /lib/firmware (or the initramfs if you load i915 from there) and pass the drm.edid_firmware=HDMI-A-1:fixed.edid option to the kernel. I'll attach the fixed EDIDs to the bug...
Created attachment 139347 [details] ASUS P238Q HDMI fixed EDID
Created attachment 139348 [details] ASUS P238Q DVI fixed EDID
HI, Ville this invalid bug?
Resolving now. Please re-open if needed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.