Can you please try to reproduce this issue with kernel 5.1 or drmtip (https://cgit.freedesktop.org/drm-tip). If persists please attach dmesg from boot with kernel parameters drm.debug=0x1e
log_buf_len=4M.

I have to be careful not to trash my system as this is a much needed production system, and I have no other hw to test.

However, I did this already with a 5.0.10 kernel (packaged by suse) with little success. I can repeat this with the most recent kernels provided by suse's packaging system (now at 5.0.11), as I don't have a full build environment for the kernel. Would that also work?

You can try the kernel in OBS Kernel:HEAD repo, which already contains 5.1 final.
  https://download.opensuse.org/repositories/Kernel:/HEAD/standard/

Super, thats cool :-)
Allow a couple of days for this, as the device is in production use.

Created attachment 144196 [details]
test with kernel 5.1.0 on openSUSE 15.0

Created attachment 144197 [details]
test with kernel 5.1.0 on openSUSE 15.0 with debug options (gzipped)

ok, done that.
see attached logs

Any news yet?

When I've tested this with the 5.1 kernel, the behaviour was worse than before.
It went into an endless loop with monitor detection. No chance to influence anything from the on-screen setup. The flickering cycles were just too fast.
The only solution to stop this was to pull the cable of the monitor out.

Can I be of help?

Recently there were some patches merged to drmtip that fixes underruns.
I recommend you to verify the issue with latest drmtip (https://cgit.freedesktop.org/drm-tip).

If issue persists with drmtip, further investigation is needed.

Created attachment 144453 [details]
test with kernel 5.2.0-rc3 on openSUSE 15.0 with debug options

Thanks for coming back

I tested with the very latest available kernel provided by opensuse being 5.2.0-rc3.

I don't know which version of the drm-tip went in there. Maybe @tiwai can tell more about this?

However, the results are negative.
The shown behaviour is again different with every patch cycle. Trying to configure the monitor is weird at best. Sometimes when I lowered the resolution to the same as the builtin one (1920x1080) the screen was occasionally showing. Most of the times not. The gui was showing the monitor as disabled when in fact it was displaying and the other way around. Trying to find a stable configuration proved to be impossible.

@Ville, any suggestion here?

I've got the very same symptoms with my Thinkpad T430, 3 external monitors (Display Port) and docking station. In my case it's OpenBSD 6.5-current after my OS vendor updated the DRM code in April from Linux 4.4 to 4.19.34.

Part of my dmesg:

inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
[drm] *ERROR* Link Training Unsuccessful

The last message is repeated 63 times.

(In reply to Norman Golisz from comment #12)
> I've got the very same symptoms with my Thinkpad T430, 3 external monitors
> (Display Port) and docking station. In my case it's OpenBSD 6.5-current
> after my OS vendor updated the DRM code in April from Linux 4.4 to 4.19.34.
> 
> Part of my dmesg:
> 
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09
> drm0 at inteldrm0
> inteldrm0: msi
> inteldrm0: 1920x1080, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
> [drm] *ERROR* Link Training Unsuccessful
> 
> The last message is repeated 63 times.

That is a different issue.

otrebor's logs show that the MST link is getting retrained, which among other things causes the FIFO underrun. I have zero faith that the current MST link retraining can do its job properly. We need to rework that code to behave more like the SST code. Ie. move the retraining to the hotplug work, make it grab the appropriate locks for all the active streams going over the same link, make sure it's not racing with ongoing commits, etc. Probably need to hoist the locking higher up into the generic hotplug code so that we can handle the multiple streams properly. Occasionally I've also pondered whether we shouldn't just throw out the special case link retraining paths and just force a full modeset for the pipe(s) in question.

In the meantime we could try to just get rid of the MST retraining code. But if the link has truly failed this will just guarantee that you get no picture:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3aef12041672..ab2da1c8e1d9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4722,15 +4722,6 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
                bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
 go_again:
                if (bret == true) {
-
-                       /* check link status - esi[10] = 0x200c */
-                       if (intel_dp->active_mst_links > 0 &&
-                           !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
-                               DRM_DEBUG_KMS("channel EQ not ok, retraining\n");
-                               intel_dp_start_link_train(intel_dp);
-                               intel_dp_stop_link_train(intel_dp);
-                       }
-
                        DRM_DEBUG_KMS("got esi %3ph\n", esi);
                        ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, &handled);

@Otrebor, Can you please provide results by applying the above diff?

I do not have a build environment for neither the kernel nor drivers. sorry.
I also do lack experience in how to do that.

For the previous tests I took a test kernel from here:
https://download.opensuse.org/repositories/Kernel:/HEAD/standard/
I that one may contain this fix, then testing that is easy.

Another private repo may work as well, as long as i get the kernel and the modules as an opensuse rpm package. Is that possible?

Stan, do you have any comments here?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/292.