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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
- Ted
Hi Ted -
On Tue, 30 Oct 2012, Theodore Ts'o <[email protected]> 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,
>
> - Ted
>
> commit 6c34ed3be47036c173f7f43df112f93fbd89026f
> Author: Jani Nikula <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Jani Nikula <[email protected]>
> Reviewed-by: Adam Jackson <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> - Ted
On Tue, 30 Oct 2012, Jani Nikula <[email protected]> wrote:
> Hi Ted -
>
> On Tue, 30 Oct 2012, Theodore Ts'o <[email protected]> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
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