Skip to contentSkip to conversation

i915: failure to interoperate with HP ZR30w using an X230

REGRESSION Theodore Ts'o 3 participants 7 messages Oct 30, 2012 – Nov 3, 2012

lore
Share & tools
lore

Theodore Ts'o

author Reviewed-by Adam Jackson
#0 lore raw

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

- Ted

#1 lore raw

Hi Ted -

Quoted 7 lines · Theodore Ts'o

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!

Quoted 7 lines

.. 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.

Quoted 1 line

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

Quoted 45 lines

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

- Ted

#2 lore raw
Quoted 30 lines · Jani Nikula

Hi Ted -

Quoted 7 lines · Theodore Ts'o

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!

Quoted 7 lines

.. 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.

Quoted 1 line

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.

Quoted 5 lines

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.

#3 lore raw
Quoted 3 lines · Jani Nikula
Quoted 1 line

[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

#4 lore raw

Ping?

Quoted 14 lines · Theodore Ts'o
Quoted 3 lines · Jani Nikula
Quoted 1 line

[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

#5 lore raw
Quoted 13 lines · Theodore Ts'o

Ping?

Quoted 10 lines · Theodore Ts'o
Quoted 3 lines · Jani Nikula
Quoted 1 line

[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

Signature · 3 lines
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
#6 lore raw
Quoted 8 lines · Daniel Vetter

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? :-)

Quoted 2 lines

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