Display port to Type-C adaptor works fine too.

(In reply to Lionel Landwerlin from comment #0)
> On drm-tip :
> 
> commit 11b7b73ccc160ecf8af7935967c25599e983e21e
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Wed Aug 28 11:15:22 2019 +0200
> 
>     drm-tip: 2019y-08m-28d-09h-13m-14s UTC integration manifest
> 
> 
> I have a monitor connected a Dell TB16 dock (through displayport or hdmi),
> itself connected to my laptop through USB Type C.
> The monitor appears detected, but no modes are detected :
> 
In this case, Can you attach the dmesg from boot with kernel parameters  drm.debug=0x1e log_buf_len=4M.

Bisected to :

commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Sat Aug 17 02:38:37 2019 -0700

    drm/i915: Fix DP-MST crtc_mask
    
    Each fake MST encoder is tied to a specific pipe. Fix the encoder's
    crtc_mask to reflect that fact.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-16-lucas.demarchi@intel.com

(In reply to Lionel Landwerlin from comment #3)
> Bisected to :
> 
> commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Sat Aug 17 02:38:37 2019 -0700
> 
>     drm/i915: Fix DP-MST crtc_mask
>     
>     Each fake MST encoder is tied to a specific pipe. Fix the encoder's
>     crtc_mask to reflect that fact.
>     
>     Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
>     Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-16-lucas.
> demarchi@intel.com

Actually the bisect is probably incorrect. Leaving the laptop/dock alone for some time seems to make things work.

Created attachment 145214 [details]
dmesg with drm.debug=0x1e when plugging the dock usb type-c cable a single time

Seems to generate a few hotplug events.

(In reply to Lionel Landwerlin from comment #5)
> Created attachment 145214 [details]
> dmesg with drm.debug=0x1e when plugging the dock usb type-c cable a single
> time
> 
> Seems to generate a few hotplug events.

Dmesg from boot would be helpful here.

@Stan, any comments?

I've looked briefly into the log. There seems to be multiple DP MST connectors detected and some modes were pruned as invalid.

Another thing is that if correspondent i915_display_info debugfs entry doesn't display anything except this:

connector 118: type DP-5, status: connected
	physical dimensions: 600x340mm
	subpixel order: Unknown
	CEA rev: 3

it means that it could not find an intel_encoder, which in turn means that encoder->pre_enable function was not called, which was supposed to assign encoder to correspondent connector. This is possible if intel_encoders_pre_enable function skips that encoder, which can happen if connector state crtc doesn't match the base crtc. So indeed that could be related to the patch you have bisected to or some other problem which makes this possible.

To check my hypothesis, I have a small patch, which will output a specific message if it skips encoder->pre_enable call, so that we know then for sure.

Please apply this patch, rebuild kernel and try again, with drm.debug enabled.

Created attachment 145216 [details] [review]
Experimental patch to reveal if we skip encoder pre_enable

(In reply to Stanislav Lisovskiy from comment #7)
> I've looked briefly into the log. There seems to be multiple DP MST
> connectors detected and some modes were pruned as invalid.
> 
> Another thing is that if correspondent i915_display_info debugfs entry
> doesn't display anything except this:
> 
> connector 118: type DP-5, status: connected
> 	physical dimensions: 600x340mm
> 	subpixel order: Unknown
> 	CEA rev: 3
> 
> it means that it could not find an intel_encoder,

That's a clear bug in i915_display_info. It should still list the modes even if there's no encoder.

(In reply to Ville Syrjala from comment #9)
> (In reply to Stanislav Lisovskiy from comment #7)
> > I've looked briefly into the log. There seems to be multiple DP MST
> > connectors detected and some modes were pruned as invalid.
> > 
> > Another thing is that if correspondent i915_display_info debugfs entry
> > doesn't display anything except this:
> > 
> > connector 118: type DP-5, status: connected
> > 	physical dimensions: 600x340mm
> > 	subpixel order: Unknown
> > 	CEA rev: 3
> > 
> > it means that it could not find an intel_encoder,
> 
> That's a clear bug in i915_display_info. It should still list the modes even
> if there's no encoder.

Yep, but there is this line:

if (!intel_encoder)
    return;

Have no clue why its there, probably it was added because in next few lines it tries to display info based on intel_encoder->type. We could just move that code:

seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
     intel_seq_print_mode(m, 2, mode);

before this condition, in order to display modes..

Created attachment 145220 [details]
dmesg with experimental patch

(In reply to Lionel Landwerlin from comment #11)
> Created attachment 145220 [details]
> dmesg with experimental patch

Looks like then there must be some other reason while there is no intel_encoder
as we don;t even see seq_printf(m, "\tmodes:\n") which should be printed anyway.

So I will look for other reason then, at least now we know that this is something else..

(In reply to Stanislav Lisovskiy from comment #12)
> (In reply to Lionel Landwerlin from comment #11)
> > Created attachment 145220 [details]
> > dmesg with experimental patch
> 
> Looks like then there must be some other reason while there is no
> intel_encoder
> as we don;t even see seq_printf(m, "\tmodes:\n") which should be printed
> anyway.
> 
> So I will look for other reason then, at least now we know that this is
> something else..

Let me know if you have any else you want to test.
I'm quite keen on having my monitor working again :)

Well you can apply that patch, which contains the fix as we discussed with Ville, that displays modes regardless of encoder presence. This will at least show if there are some modes discovered.

Please try this attachment.

Created attachment 145234 [details] [review]
List modes even without encoder

PS: Meanwhile I will try to investigate and possible add more debugs to existing code in order to understand when we start to miss that encoder assignment.

(In reply to Stanislav Lisovskiy from comment #14)
> Well you can apply that patch, which contains the fix as we discussed with
> Ville, that displays modes regardless of encoder presence. This will at
> least show if there are some modes discovered.
> 
> Please try this attachment.

With this patch the modes appear :

connector 106: type DP-4, status: connected
	physical dimensions: 600x340mm
	subpixel order: Unknown
	CEA rev: 3
	modes:
		"2560x1440": 60 241500 2560 2608 2640 2720 1440 1443 1448 1481 0x48 0x9
		"2048x1152": 60 162000 2048 2074 2154 2250 1152 1153 1156 1200 0x40 0x5
		"1920x1200": 60 193250 1920 2056 2256 2592 1200 1203 1209 1245 0x40 0x6
		"1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 30 74250 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 30 74176 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 25 74250 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5
		"1920x1080": 24 74176 1920 2558 2602 2750 1080 1084 1089 1125 0x40 0x5
		"1600x1200": 60 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x40 0x5
		"1680x1050": 60 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6
		"1280x1024": 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
		"1280x1024": 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
		"1200x960": 60 95403 1200 1272 1400 1600 960 961 964 994 0x0 0x6
		"1152x864": 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
		"1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
		"1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
		"1280x720": 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
		"1280x720": 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
		"1024x768": 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5
		"1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
		"800x600": 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5
		"800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
		"720x576": 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
		"720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
		"720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
		"720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
		"720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
		"720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
		"640x480": 75 31500 640 656 720 840 480 481 484 500 0x40 0xa
		"640x480": 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
		"640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
		"640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
		"720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6
	audio support: yes

Another piece of information that might help to pin the issue, I can boot the system with both monitor (internal/external) showing the same thing and even in GDM, I'm able to log in and see that both monitors are setup and properly configured to show at least a background on the external monitor and the logging screen on the internal monitor.

The issue appears after the hand-off from GDM to the gnome-shell session of the user. At no point was the monitor disconnected, so maybe that's nothing to do with hotplug events?

(In reply to Lionel Landwerlin from comment #18)
> Another piece of information that might help to pin the issue, I can boot
> the system with both monitor (internal/external) showing the same thing and
> even in GDM, I'm able to log in and see that both monitors are setup and
> properly configured to show at least a background on the external monitor
> and the logging screen on the internal monitor.
> 
> The issue appears after the hand-off from GDM to the gnome-shell session of
> the user. At no point was the monitor disconnected, so maybe that's nothing
> to do with hotplug events?

Does the display work in console mode? I mean if you boot with "3" option in the kernel command line.

(In reply to Stanislav Lisovskiy from comment #19)
> (In reply to Lionel Landwerlin from comment #18)
> > Another piece of information that might help to pin the issue, I can boot
> > the system with both monitor (internal/external) showing the same thing and
> > even in GDM, I'm able to log in and see that both monitors are setup and
> > properly configured to show at least a background on the external monitor
> > and the logging screen on the internal monitor.
> > 
> > The issue appears after the hand-off from GDM to the gnome-shell session of
> > the user. At no point was the monitor disconnected, so maybe that's nothing
> > to do with hotplug events?
> 
> Does the display work in console mode? I mean if you boot with "3" option in
> the kernel command line.

I'll need to check when I'm near the dock again for switching to the console mode. But at boot time, yes it does work.

Where does the "3" value goes?

It is kernel command line, which can be edited same way as you add drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks like "drm.debug=0x1e 3". This will make it boot into console mode, without GUI, however if it works
that way we will know at least whether this is GDM messing up things or some problem in the kernel.

(In reply to Stanislav Lisovskiy from comment #21)
> It is kernel command line, which can be edited same way as you add
> drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks
> like "drm.debug=0x1e 3". This will make it boot into console mode, without
> GUI, however if it works
> that way we will know at least whether this is GDM messing up things or some
> problem in the kernel.

I don't have a splash screen during the boot, so before GDM starts, I can see the console on both monitors. Is that what you wanted to know?

(In reply to Lionel Landwerlin from comment #22)
> (In reply to Stanislav Lisovskiy from comment #21)
> > It is kernel command line, which can be edited same way as you add
> > drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks
> > like "drm.debug=0x1e 3". This will make it boot into console mode, without
> > GUI, however if it works
> > that way we will know at least whether this is GDM messing up things or some
> > problem in the kernel.
> 
> I don't have a splash screen during the boot, so before GDM starts, I can
> see the console on both monitors. Is that what you wanted to know?

How about unplug/plug the display in the console mode? Does it work reliably?

(In reply to Stanislav Lisovskiy from comment #19)
> (In reply to Lionel Landwerlin from comment #18)
> > Another piece of information that might help to pin the issue, I can boot
> > the system with both monitor (internal/external) showing the same thing and
> > even in GDM, I'm able to log in and see that both monitors are setup and
> > properly configured to show at least a background on the external monitor
> > and the logging screen on the internal monitor.
> > 
> > The issue appears after the hand-off from GDM to the gnome-shell session of
> > the user. At no point was the monitor disconnected, so maybe that's nothing
> > to do with hotplug events?
> 
> Does the display work in console mode? I mean if you boot with "3" option in
> the kernel command line.

The external monitor works again as soon as switch to a virtual console.
So looks like an application issue?

It's weird that going back to an older kernel I don't run into the issue.

(In reply to Stanislav Lisovskiy from comment #23)
> (In reply to Lionel Landwerlin from comment #22)
> > (In reply to Stanislav Lisovskiy from comment #21)
> > > It is kernel command line, which can be edited same way as you add
> > > drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks
> > > like "drm.debug=0x1e 3". This will make it boot into console mode, without
> > > GUI, however if it works
> > > that way we will know at least whether this is GDM messing up things or some
> > > problem in the kernel.
> > 
> > I don't have a splash screen during the boot, so before GDM starts, I can
> > see the console on both monitors. Is that what you wanted to know?
> 
> How about unplug/plug the display in the console mode? Does it work reliably?

Yep, works fine.

(In reply to Lionel Landwerlin from comment #25)
> (In reply to Stanislav Lisovskiy from comment #23)
> > (In reply to Lionel Landwerlin from comment #22)
> > > (In reply to Stanislav Lisovskiy from comment #21)
> > > > It is kernel command line, which can be edited same way as you add
> > > > drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks
> > > > like "drm.debug=0x1e 3". This will make it boot into console mode, without
> > > > GUI, however if it works
> > > > that way we will know at least whether this is GDM messing up things or some
> > > > problem in the kernel.
> > > 
> > > I don't have a splash screen during the boot, so before GDM starts, I can
> > > see the console on both monitors. Is that what you wanted to know?
> > 
> > How about unplug/plug the display in the console mode? Does it work reliably?
> 
> Yep, works fine.

Please "Revert "drm/i915: Fix DP-MST crtc_mask" from Ville, most likely the issue is caused by this. Ville's change itself was correct as I understand however Mutter and some other userspace apps does some stuff like "intersecting" possible crtc mask which results to 0 after this change. For console as we checked it does it properly, which explains why you don't have it there.
So please revert this change you had bisected to and check if that helps.

(In reply to Stanislav Lisovskiy from comment #26)
> (In reply to Lionel Landwerlin from comment #25)
> > (In reply to Stanislav Lisovskiy from comment #23)
> > > (In reply to Lionel Landwerlin from comment #22)
> > > > (In reply to Stanislav Lisovskiy from comment #21)
> > > > > It is kernel command line, which can be edited same way as you add
> > > > > drm.debug=0x1e in grub.cfg, just add 3 after drm.debug, so that it looks
> > > > > like "drm.debug=0x1e 3". This will make it boot into console mode, without
> > > > > GUI, however if it works
> > > > > that way we will know at least whether this is GDM messing up things or some
> > > > > problem in the kernel.
> > > > 
> > > > I don't have a splash screen during the boot, so before GDM starts, I can
> > > > see the console on both monitors. Is that what you wanted to know?
> > > 
> > > How about unplug/plug the display in the console mode? Does it work reliably?
> > 
> > Yep, works fine.
> 
> Please "Revert "drm/i915: Fix DP-MST crtc_mask" from Ville, most likely the
> issue is caused by this. Ville's change itself was correct as I understand
> however Mutter and some other userspace apps does some stuff like
> "intersecting" possible crtc mask which results to 0 after this change. For
> console as we checked it does it properly, which explains why you don't have
> it there.
> So please revert this change you had bisected to and check if that helps.

Like I wrote earlier, the bisect was wrong. Sometimes the monitor will manage to work and that screwed up the bisect.

Reverting that one patch doesn't actually help.

> 
> Like I wrote earlier, the bisect was wrong. Sometimes the monitor will
> manage to work and that screwed up the bisect.
> 
> Reverting that one patch doesn't actually help.

Ok, then we are dealing with something else. However if the console mode works all the time it is quite likely that it is userspace again.

I have seen similar issue quite a lot when it was simply a userspace issue.

Also you can try to force a modeset using xrandr.

(In reply to Stanislav Lisovskiy from comment #28)
> > 
> > Like I wrote earlier, the bisect was wrong. Sometimes the monitor will
> > manage to work and that screwed up the bisect.
> > 
> > Reverting that one patch doesn't actually help.
> 
> Ok, then we are dealing with something else. However if the console mode
> works all the time it is quite likely that it is userspace again.
> 
> I have seen similar issue quite a lot when it was simply a userspace issue.
> 
> Also you can try to force a modeset using xrandr.

I don't think I can when using a gnome-shell wayland session.

I gave another try on drm-tip : 

commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Sep 4 18:53:26 2019 +0300

    drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest

which includes this commit :

commit e838bfa8e170415fa3cc8e83ecb171e809c0c422
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Sep 3 18:40:18 2019 +0300

    Revert "drm/i915: Fix DP-MST crtc_mask"
    
    This reverts commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f.


But the problem is still there.

I think I have found something interesting. For DP-1 connector ocassionally despite received hotplug event intel_dp_detect function seems to exit prematurely. 

Like normally it should look like this:

[ 1244.458373] [drm:intel_dp_detect [i915]] [CONNECTOR:100:DP-1]
[ 1244.459728] [drm:intel_dp_read_dpcd [i915]] DPCD: 12 14 c4 00 00 05 01 83 02 00 00 00 00 00 02
[ 1244.461024] [drm:drm_dp_read_desc [drm_kms_helper]] DP branch: OUI 90-cc-24 dev-ID SYNA30 HW-rev 1.0 SW-rev 3.10 quirks 0x0000
[ 1244.463838] [drm:intel_dp_print_rates [i915]] source rates: 162000, 216000, 270000, 324000, 432000, 540000
[ 1244.463858] [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000, 540000
[ 1244.463875] [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000, 540000
[ 1244.465111] [drm:intel_dp_detect [i915]] MST support? port C: yes, sink: yes, modparam: yes

However in the log "dmesg with drm.debug=0x1e when plugging the dock usb type-c cable a single time" the last hotplug event for DP-1 looks like this:

[ 1245.482006] [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 5) received hotplug event.
[ 1245.482093] [drm:intel_dp_detect [i915]] [CONNECTOR:92:DP-1]

So not even showing sink rates means that it was determined as disconnected and intel_dp_read_dpcd probably failed.
However this port was already disconnected before in the log:

[ 1244.181015] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[ 1244.181148] [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 5) received hotplug event.
[ 1244.181272] [drm:intel_dp_detect [i915]] [CONNECTOR:92:DP-1]
[ 1244.181769] [drm:intel_dp_detect [i915]] MST device may have disappeared 1 vs 1
[ 1244.181983] [drm:intel_power_well_enable [i915]] enabling DC off
[ 1244.182402] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
[ 1244.182951] [drm:intel_power_well_enable [i915]] enabling power well 2
[ 1244.191512] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff
 ...
[ 1244.445543] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff
[ 1244.454008] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7d4003ff
[ 1244.454017] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110

Which makes this all look a little suspicious.

FYI, on 

commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Sep 4 18:53:26 2019 +0300

    drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest

Things are working sometimes. Usually if I reboot the machine and it works, it'll keep working, if it doesn't work at boot, it won't ever work it seems.

Not quite sure where the issue lies...

(In reply to Lionel Landwerlin from comment #32)
> FYI, on 
> 
> commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Wed Sep 4 18:53:26 2019 +0300
> 
>     drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest
> 
> Things are working sometimes. Usually if I reboot the machine and it works,
> it'll keep working, if it doesn't work at boot, it won't ever work it seems.
> 
> Not quite sure where the issue lies...

Does it recover ever if you try to replug it?

One good thing to try: I think you mentioned that it was working on some older kernel. Can you please get a dmesg from that one. Just do a single unplug and plug. Then do the same with new kernel, so that it would be then possible to compare those logs.

I'm really curious what is the issue, however looks like I can't reproduce it with my machine, even though I also have TB16 connected through usb-c.

(In reply to Stanislav Lisovskiy from comment #33)
> (In reply to Lionel Landwerlin from comment #32)
> > FYI, on 
> > 
> > commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
> > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Date:   Wed Sep 4 18:53:26 2019 +0300
> > 
> >     drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest
> > 
> > Things are working sometimes. Usually if I reboot the machine and it works,
> > it'll keep working, if it doesn't work at boot, it won't ever work it seems.
> > 
> > Not quite sure where the issue lies...
> 
> Does it recover ever if you try to replug it?

Nop, it doesn't recover.

> 
> One good thing to try: I think you mentioned that it was working on some
> older kernel. Can you please get a dmesg from that one. Just do a single
> unplug and plug. Then do the same with new kernel, so that it would be then
> possible to compare those logs.
> 
> I'm really curious what is the issue, however looks like I can't reproduce
> it with my machine, even though I also have TB16 connected through usb-c.

Will try this later. I can even provide a log with the same version when it's working.

(In reply to Lionel Landwerlin from comment #34)
> (In reply to Stanislav Lisovskiy from comment #33)
> > (In reply to Lionel Landwerlin from comment #32)
> > > FYI, on 
> > > 
> > > commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
> > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Date:   Wed Sep 4 18:53:26 2019 +0300
> > > 
> > >     drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest
> > > 
> > > Things are working sometimes. Usually if I reboot the machine and it works,
> > > it'll keep working, if it doesn't work at boot, it won't ever work it seems.
> > > 
> > > Not quite sure where the issue lies...
> > 
> > Does it recover ever if you try to replug it?
> 
> Nop, it doesn't recover.

I should add I've also tried to unpower the dock etc... Nothing brings the external monitor back. Only laptop reboot will do.

> 
> > 
> > One good thing to try: I think you mentioned that it was working on some
> > older kernel. Can you please get a dmesg from that one. Just do a single
> > unplug and plug. Then do the same with new kernel, so that it would be then
> > possible to compare those logs.
> > 
> > I'm really curious what is the issue, however looks like I can't reproduce
> > it with my machine, even though I also have TB16 connected through usb-c.
> 
> Will try this later. I can even provide a log with the same version when
> it's working.

(In reply to Lionel Landwerlin from comment #35)
> (In reply to Lionel Landwerlin from comment #34)
> > (In reply to Stanislav Lisovskiy from comment #33)
> > > (In reply to Lionel Landwerlin from comment #32)
> > > > FYI, on 
> > > > 
> > > > commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
> > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Date:   Wed Sep 4 18:53:26 2019 +0300
> > > > 
> > > >     drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest
> > > > 
> > > > Things are working sometimes. Usually if I reboot the machine and it works,
> > > > it'll keep working, if it doesn't work at boot, it won't ever work it seems.
> > > > 
> > > > Not quite sure where the issue lies...
> > > 
> > > Does it recover ever if you try to replug it?
> > 
> > Nop, it doesn't recover.
> 
> I should add I've also tried to unpower the dock etc... Nothing brings the
> external monitor back. Only laptop reboot will do.
> 

But you wrote that "The external monitor works again as soon as switch to a virtual console." Is it still true? Or it doesn't help always?

(In reply to Stanislav Lisovskiy from comment #36)
> (In reply to Lionel Landwerlin from comment #35)
> > (In reply to Lionel Landwerlin from comment #34)
> > > (In reply to Stanislav Lisovskiy from comment #33)
> > > > (In reply to Lionel Landwerlin from comment #32)
> > > > > FYI, on 
> > > > > 
> > > > > commit cde3db21383e3c077c278ba783e4ec8d006f2e32 (drm-tip/drm-tip)
> > > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Date:   Wed Sep 4 18:53:26 2019 +0300
> > > > > 
> > > > >     drm-tip: 2019y-09m-04d-15h-52m-25s UTC integration manifest
> > > > > 
> > > > > Things are working sometimes. Usually if I reboot the machine and it works,
> > > > > it'll keep working, if it doesn't work at boot, it won't ever work it seems.
> > > > > 
> > > > > Not quite sure where the issue lies...
> > > > 
> > > > Does it recover ever if you try to replug it?
> > > 
> > > Nop, it doesn't recover.
> > 
> > I should add I've also tried to unpower the dock etc... Nothing brings the
> > external monitor back. Only laptop reboot will do.
> > 
> 
> But you wrote that "The external monitor works again as soon as switch to a
> virtual console." Is it still true? Or it doesn't help always?

Oh yeah sorry, I meant with Gnome.
Thing is, the virtual console seems to use a completely different path. Last time I tried to look at the diff of traces, nothing matched (virtual console logs where much much shorter).

Not able to reproduce anymore. Should we close?