Since the upgrade from kernel 3.4.x (the whole 3.4 series is fine) to the 3.5.1, whenever I plug my external VGA monitor to the laptop even if I do not set it to be used, the messages log gets spammed with fragments like this: drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [drm:drm_edid_block_valid] *ERROR* Raw EDID: <3>00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Also, the resolution at which I can set the screen has been redoced from 1280x1024 to 1024x768. I can force it to work at 1280x1024 using xrandr to add a new mode but whenever I do this, the screen gets moved to the left, leaving a black vertical artifact at the right of the VGA screen. Also, the screen gets moved to the right like 120 px or something between 120 and 80 px Aside from the external screen problem, everything else seems to work and no X or kernel crashes have been suffered. This bug report is almost a copy of a regression that also happened on 2.6.39 as the behaviour seems to be the same: https://bugzilla.kernel.org/show_bug.cgi?id=36662 I'm already on bisecting between 3.4.8 and 3.5.1 to see where this got broken again. In case I've left something out that should have been added here, please tell me.
Created attachment 77361 [details] Dmesg output
Can you attach an 'xrandr --verbose' for the working 3.4 setup?
Created attachment 77371 [details] Output of xrandr --verbose using 3.4.8 kernel
Do you also want me to attach the output of 'xrandr --verbose' for the 3.5 kernel?
(In reply to comment #4) > Do you also want me to attach the output of 'xrandr --verbose' for the 3.5 > kernel? No, I was curious as to what the EDID should be. :)
Already reported here: https://lkml.org/lkml/2012/7/25/77 I've volunteered Jani to implement the workaround for it. Unfortunately he's not yet on kernel bugzilla, I'll yell at him a bit.
the patch suggested in the mailing list's thread solves the problem for me.
(In reply to comment #6) > I've volunteered Jani to implement the workaround for it. Unfortunately he's > not yet on kernel bugzilla, I'll yell at him a bit. Yessir! I'm here now. (In reply to comment #7) > the patch suggested in the mailing list's thread solves the problem for me. Please try the polished version posted in the list, and let use have your tested-by. Thanks.
I'll try to test it as soon as possible, but I'm not sure I'll be able to test it before Thursday.
Created attachment 77621 [details] [PATCH 1/2] drm/i915: extract connector update from intel_ddc_get_modes() for reuse
Created attachment 77631 [details] [PATCH 2/2] drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
second patch fails to apply HUNK #2 because there is a comment block between i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); edid = drm_get_edid(connector, i2c); and if (edid) { bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL; Anyway, changed manually that part and I'm currently building the kernel.
Problem seems to be solved with those two patches, however dmesg still gets "spammed" with [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 I'll attach the output of dmesg
Created attachment 77801 [details] dmesg output after applying the two proposed patches
Thanks for the testing! (In reply to comment #12) > second patch fails to apply HUNK #2 because there is a comment block between > > i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin); > edid = drm_get_edid(connector, i2c); > > and > > if (edid) { > bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL; > > > Anyway, changed manually that part and I'm currently building the kernel. I think this means you're applying the patch on top of kernel 3.5. Is that right? Before we apply the fix, I think it would be useful if you could test this on current master, or better yet, drm-intel-fixes branch of git://people.freedesktop.org/~danvet/drm-intel repo. Without and with the patches. (In reply to comment #13) > Problem seems to be solved with those two patches, however dmesg still gets > "spammed" with [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, > remainder is 130 This is the GMBUS failure as before, but the patches add a fallback mechanism to use in this failure mode. If tried with the drm.debug=0xe module parameter, I think you'd see the "CRT GMBUS EDID read failed, retry using GPIO bit-banging" debug message.
Yes, I was applying the patch on top of 3.5, specifically 3.5.2 ( latest stable release) I'll test it with drm-intel-fixes branch as soon as I can, but I fear it could not be possible until tomorrow.
Well, tested drm-intel-fixes branch from the git repo you posted and: unpatched: dmesg gets spammed and the issue reported at the beginning of the thread exists. patched: dmesg still gets spammed about the EDID checksum, but issue is gone
(In reply to comment #17) > Well, tested drm-intel-fixes branch from the git repo you posted and: > > unpatched: dmesg gets spammed and the issue reported at the beginning of the > thread exists. > > patched: dmesg still gets spammed about the EDID checksum, but issue is gone Thanks again for testing. Daniel has queued the fix, and the dmesg spam will be looked into separately.
(In reply to comment #18) > Thanks again for testing. Daniel has queued the fix, and the dmesg spam will > be > looked into separately. Thank you for your time solving the issue. I'm glad I've been able to help
The fix landed in 3.6-rc2, cc: stable. commit f1a2f5b7c5f0941d23eef0a095c0b99bf8d051e6 Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Aug 13 13:22:35 2012 +0300 drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads
A patch referencing this bug report has been merged in Linux v3.6-rc3: commit 4eab81366465aedcfd26de960c595bc03599c09f Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Aug 13 13:22:34 2012 +0300 drm/i915: extract connector update from intel_ddc_get_modes() for reuse