I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able to work with an HP ZR30w 30" 2560x1600 display. I saw the following messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I didn't see before; the exact same mini-displayport to displayport cable connecting the same Lenovo X230 laptop to exactly the same ZRW 30 display worked just fine with the 3.6.0 kernel.
So I bisected the problem, and found the following commit. Reverting this commit made the problem go away. Maybe we should revert 0c96c65b48fb in mainline?
Let me know if you'd like me to do any further debugging.
Thanks,
- Ted
commit 6c34ed3be47036c173f7f43df112f93fbd89026f Author: Jani Nikula jani.nikula@intel.com Date: Wed Sep 26 18:43:10 2012 +0300
drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream.
The dithering introduced in
commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson ajax@redhat.com Date: Tue Dec 13 15:41:00 2011 -0800
drm/i915/dp: Dither down to 6bpc if it makes the mode fit
stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in
commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Aug 10 11:10:20 2012 +0200
Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson ajax@redhat.com Signed-off-by: Jani Nikula jani.nikula@intel.com Reviewed-by: Adam Jackson ajax@redhat.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
- Ted
Hi Ted -
On Tue, 30 Oct 2012, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able to work with an HP ZR30w 30" 2560x1600 display. I saw the following messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I didn't see before; the exact same mini-displayport to displayport cable connecting the same Lenovo X230 laptop to exactly the same ZRW 30 display worked just fine with the 3.6.0 kernel.
So I bisected the problem, and found the following commit. Reverting this commit made the problem go away. Maybe we should revert 0c96c65b48fb in mainline?
Thanks for bisecting. However, the commit does fix a bug for some people out there, which is why it's been backported to stable. Without it, we fail to dither when there is not enough bandwidth in the DP link. My guess is that this brings up another bug that affects you, and IMHO we'd be better off debugging this than reverting.
Let me know if you'd like me to do any further debugging.
Something to try would be the latest i915.ko driver [1], which I believe has some link training changes, and/or posting the dmesg with drm.debug=0xe module parameter.
BR, Jani.
[1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel
Thanks,
- Tedcommit 6c34ed3be47036c173f7f43df112f93fbd89026f Author: Jani Nikula jani.nikula@intel.com Date: Wed Sep 26 18:43:10 2012 +0300
drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream. The dithering introduced in commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson <ajax@redhat.com> Date: Tue Dec 13 15:41:00 2011 -0800 drm/i915/dp: Dither down to 6bpc if it makes the mode fit stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect. v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson <ajax@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Ted
On Tue, 30 Oct 2012, Jani Nikula jani.nikula@intel.com wrote:
Hi Ted -
On Tue, 30 Oct 2012, Theodore Ts'o tytso@mit.edu wrote:
I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able to work with an HP ZR30w 30" 2560x1600 display. I saw the following messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I didn't see before; the exact same mini-displayport to displayport cable connecting the same Lenovo X230 laptop to exactly the same ZRW 30 display worked just fine with the 3.6.0 kernel.
So I bisected the problem, and found the following commit. Reverting this commit made the problem go away. Maybe we should revert 0c96c65b48fb in mainline?
Thanks for bisecting. However, the commit does fix a bug for some people out there, which is why it's been backported to stable. Without it, we fail to dither when there is not enough bandwidth in the DP link. My guess is that this brings up another bug that affects you, and IMHO we'd be better off debugging this than reverting.
Let me know if you'd like me to do any further debugging.
Something to try would be the latest i915.ko driver [1], which I believe has some link training changes, and/or posting the dmesg with drm.debug=0xe module parameter.
BR, Jani.
[1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Daniel, 'git tag --contains 0c96c65b48fba3ffe9822a554cbc0cd610765cd5' says the commit is upstream since v3.7-rc1, and you backmerged v3.7-rc2 to drm-intel-next-queued with c2fb7916927e989ea424e61ce5fe617e54878827, but the adjusted_mode fix is nowhere to be seen. Did something go wrong with the backmerge, or am I missing something?
BR, Jani.
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree (3.7.0-rc2-00031-g1623392) works fine for me.
Do you know which commit(s) are likely to have fixed the problem, so we can cherry pick the appropriate fix(es) to the 3.6.x tree?
Thanks,
- Ted
Ping?
On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote:
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree (3.7.0-rc2-00031-g1623392) works fine for me.
Do you know which commit(s) are likely to have fixed the problem, so we can cherry pick the appropriate fix(es) to the 3.6.x tree?
Thanks,
- Ted
On Fri, Nov 02, 2012 at 08:58:31PM -0400, Theodore Ts'o wrote:
Ping?
On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote:
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree (3.7.0-rc2-00031-g1623392) works fine for me.
Do you know which commit(s) are likely to have fixed the problem, so we can cherry pick the appropriate fix(es) to the 3.6.x tree?
Well, we know for sure that fdi link training is broken - it doesn't match at all what the spec says we should do. I've been working on this lately, since in quite a few circumstances the link train fails without the relevent bits indicating so. While testing I've also noticed that this entire thing is highly timing dependent, e.g. denpending upon which desktop is running and which tool I use to change the configuration it fails or succeeds.
So I have no suggestions for what could help your system and what should get backported, since the current code is still broken. -Daniel
On Sat, Nov 03, 2012 at 11:21:58AM +0100, Daniel Vetter wrote:
Well, we know for sure that fdi link training is broken - it doesn't match at all what the spec says we should do. I've been working on this lately, since in quite a few circumstances the link train fails without the relevent bits indicating so. While testing I've also noticed that this entire thing is highly timing dependent, e.g. denpending upon which desktop is running and which tool I use to change the configuration it fails or succeeds.
So it is still (somewhat) broken in 3.7-rcX? Certainly it seems to be better (at least for me) than what was in 3.6.3. Or are you saying I may have just gotten lucky? :-)
So I have no suggestions for what could help your system and what should get backported, since the current code is still broken.
Thanks for your response and for your work in making the i915 driver better. I really appreciate your efforts.
Cheers,
- Ted
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Jani Nikula -
Theodore Ts'o