Created attachment 145149 [details]
dmesg booting connected with dock (beginnig missing)

Created attachment 145150 [details]
end of dmesg after drm stopped spamming the log

Let me know if I can do anything more or if additional information is needed.

From "dmesg connecting dock with monitor and activating it " I couldn't find any errors/failures indicating a kernel issue.


From "dmesg booting connected with dock (beginnig missing)" even though the log is not from boot I notice that 
24.879406] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:99:DP-2] Link Training failed at link rate = 540000, lane count = 4

From "end of dmesg after drm stopped spamming the log " 
[  374.881814] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
[  374.881962] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:99:DP-2] Link Training failed at link rate = 162000, lane count = 2

Can you please verify the issue with drmtip (https://cgit.freedesktop.org/drm-tip)? Please attach the full dmesg log from boot if the problem persists with drmtip.

Also when the issue occurred can you attach display info
cat /sys/kernel/debug/dri/0/i915_display_info

Ok, sorry that this took so long, but I finally had time.
So what I did is booting with the dock attached and the monitor connected through the HDMI port.
After this I logged into a tty and did:
dmesg > dmesg_drm*
then dmesg -w >> dmesg_drm*
After this I waited a bit and logged into another tty which starts an X server.
And I just switched a bit between the X server and the tty.
In one case, I got a blackscreen and could not do anything anymore (dmesg_drm2) so I had to poweroff the laptop by pressing the power button.
I'm currently typing this from the other attached boot.
I can use the X server normally but the monitor does not show anything despite xrandr telling that it is connected.

Created attachment 145185 [details]
dmesg_drm2

Created attachment 145186 [details]
dmesg_drm3

Created attachment 145187 [details]
i915_display_info

Created attachment 145188 [details]
xrandr_output

(In reply to Joseph Thommes from comment #8)
> Created attachment 145187 [details]
> i915_display_info

Is it connected through HDMI here? 
Are these results from drmtip? If not, can you please verify the issue with drmtip?

Yes the monitor is connected through the HDMI port of the dock and yes this was with the drmtip kernel.

(In reply to Joseph Thommes from comment #6)
> Created attachment 145185 [details]
> dmesg_drm2

(In reply to Joseph Thommes from comment #7)
> Created attachment 145186 [details]
> dmesg_drm3

Can you attach from boot(from 0 seconds)?

(In reply to Lakshmi from comment #12)
> (In reply to Joseph Thommes from comment #6)
> > Created attachment 145185 [details]
> > dmesg_drm2
> 
> (In reply to Joseph Thommes from comment #7)
> > Created attachment 145186 [details]
> > dmesg_drm3
> 
> Can you attach from boot(from 0 seconds)?

Can you please attach the full log?

Hi everyone,
I finally had time to recompile the kernel and perform the procedure again, but this time with sufficient memory for logging. So please find the new log attached. If there is anything more I can do, let me know.

Created attachment 145677 [details]
Complete log with monitor attached

(In reply to Joseph Thommes from comment #14)
> Hi everyone,
> I finally had time to recompile the kernel and perform the procedure again,
> but this time with sufficient memory for logging. So please find the new log
> attached. If there is anything more I can do, let me know.

Have you tried to connect the external monitor directly to the laptop (through HDMI). Was it working fine?

How do you recover from the situation?

Hi,
yes the monitors work just fine when connected to the laptop directly.
What exactly do you mean with recover?
In the case of the last log, I had to forcefully power off my laptop as it was completely stuck. If I pull the HDMI cable before, I can just continue working with the laptop, but if I wait long enough, it will get stuck.

(In reply to Joseph Thommes from comment #17)
> Hi,
> yes the monitors work just fine when connected to the laptop directly.
> What exactly do you mean with recover?
> In the case of the last log, I had to forcefully power off my laptop as it
> was completely stuck. If I pull the HDMI cable before, I can just continue
> working with the laptop, but if I wait long enough, it will get stuck.

Ok, thanks for the answer. 

Setting the priority and severity of the issue based on the impact.

Have you tried booting only console with same setup? So add these drm.debug=0xe log_buf_len=1M 3 and report if this helps.

Created attachment 145697 [details]
dmesg_drm_debug=0xe

I started the laptop in the dock with the monitor connected. I did dmesg -w | tee "file" in a tty. After the spamming of the kernel stopped, I logged into my X-Session and tried to change the solution of the monitor (which was shown as active and detected, but nothing arrived at it) to 3840x2160 in arandr (which is the maximum it can handle) and at this point my computer got completely stuck. Pulling the hdmi and even disconnecting the dock both did not work and I had to forcefully power off my PC.
Note that the monitor from this and the last time is not the same as in the beginning (actually this time it's a TV), but the same problem shows. Sadly I do not have access to the first monitor until christmas, if that would be necessary.

I don't know what exactly you mean with only console. Do you mean not starting a login manager/x-session? If you mean it like this, then yes, this is my standard setup. I need to login in tty1 to start a X session. If I do it in another tty, no X server is started.

(In reply to Joseph Thommes from comment #17)
> Hi,
> yes the monitors work just fine when connected to the laptop directly.
> What exactly do you mean with recover?
> In the case of the last log, I had to forcefully power off my laptop as it
> was completely stuck. If I pull the HDMI cable before, I can just continue
> working with the laptop, but if I wait long enough, it will get stuck.

@Stan, any help here?

Seems like one more MST issue, we had similar issues before and it is well known that some displays/docks behave in a weird way while in MST mode. Like setting weird dpcd values, sink count and whatever.

Need additional investigation, regarding what is wrong in this particular case, I think I have a similar display on my table now, so once I finish with that once, fix might help here as well(if it is curable at all).

As for computer hang, I guess this is related to that dmesg seems to be flooded with spurious hpd(hotplug) irqs and seems that irq storm detection didn't help here.

Currently the only thing to check is that whether does it behave same way on console mode(guess it does) and try to force the display to non-mst mode(in display menu there can be such option).

Stan, do you have any proposal / patches to try on this at the moment?

Reporter, can you try with todays drm-tip. One bug was fixed/merged = 112212 and with that kernel I tested DP MST on Dell XPS (Kabylake) and worked well. Please try with latest drm-tip.

Today I built the latest drm-tip kernel and indeed the issues have gone, so it appears, that everything has been fixed. I could however only test with the HDMI port.

Ok, thanks for reporting back.