Bug 111507 - Unable to detect monitor modes connected to a TB16 Dell dock
Summary: Unable to detect monitor modes connected to a TB16 Dell dock
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: high major
Assignee: Stanislav Lisovskiy
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-28 10:56 UTC by Lionel Landwerlin
Modified: 2019-09-17 14:03 UTC (History)
2 users (show)

See Also:
i915 platform: KBL
i915 features: display/Other


Attachments
dmesg with drm.debug=0x1e when plugging the dock usb type-c cable a single time (125.70 KB, text/plain)
2019-08-29 21:58 UTC, Lionel Landwerlin
no flags Details
Experimental patch to reveal if we skip encoder pre_enable (1.08 KB, patch)
2019-08-30 07:49 UTC, Stanislav Lisovskiy
no flags Details | Splinter Review
dmesg with experimental patch (125.55 KB, text/plain)
2019-08-30 15:16 UTC, Lionel Landwerlin
no flags Details
List modes even without encoder (1.41 KB, patch)
2019-09-02 11:23 UTC, Stanislav Lisovskiy
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Landwerlin 2019-08-28 10:56:20 UTC
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 :

From /sys/kernel/debug/dri/0/i915_display_info

Connector info
--------------
connector 86: type eDP-1, status: connected
	physical dimensions: 290x170mm
	subpixel order: Unknown
	CEA rev: 0
	DPCD rev: 12
	audio support: no
	fixed mode:
		"3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa
	DP branch device present: no
	modes:
		"3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa
		"3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa
connector 92: type DP-1, status: disconnected
connector 100: type DP-2, status: disconnected
connector 109: type DP-4, status: disconnected
connector 105: type DP-3, status: disconnected
connector 118: type DP-5, status: connected
	physical dimensions: 600x340mm
	subpixel order: Unknown
	CEA rev: 3
connector 135: type DP-6, status: disconnected
connector 137: type DP-7, status: disconnected
connector 139: type DP-8, status: disconnected

The monitor works fine if I connect it directly to the laptop (through HDMI -> type-C adaptor).

I tried to bisect things, but it seems somewhat unreliable. It seemed to work fine on earlier RC of 5.3.0
Comment 1 Lionel Landwerlin 2019-08-28 10:57:30 UTC
Display port to Type-C adaptor works fine too.
Comment 2 Lakshmi 2019-08-29 07:52:07 UTC
(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.
Comment 3 Lionel Landwerlin 2019-08-29 10:49:40 UTC
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
Comment 4 Lionel Landwerlin 2019-08-29 21:56:27 UTC
(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.
Comment 5 Lionel Landwerlin 2019-08-29 21:58:05 UTC
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.
Comment 6 Lakshmi 2019-08-30 06:40:51 UTC
(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?
Comment 7 Stanislav Lisovskiy 2019-08-30 07:48:29 UTC
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.
Comment 8 Stanislav Lisovskiy 2019-08-30 07:49:27 UTC
Created attachment 145216 [details] [review]
Experimental patch to reveal if we skip encoder pre_enable
Comment 9 Ville Syrjala 2019-08-30 12:38:58 UTC
(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.
Comment 10 Stanislav Lisovskiy 2019-08-30 13:17:27 UTC
(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..
Comment 11 Lionel Landwerlin 2019-08-30 15:16:42 UTC
Created attachment 145220 [details]
dmesg with experimental patch
Comment 12 Stanislav Lisovskiy 2019-09-02 06:59:51 UTC
(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..
Comment 13 Lionel Landwerlin 2019-09-02 11:01:45 UTC
(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 :)
Comment 14 Stanislav Lisovskiy 2019-09-02 11:22:55 UTC
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.
Comment 15 Stanislav Lisovskiy 2019-09-02 11:23:29 UTC
Created attachment 145234 [details] [review]
List modes even without encoder
Comment 16 Stanislav Lisovskiy 2019-09-02 11:27:51 UTC
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.
Comment 17 Lionel Landwerlin 2019-09-02 14:50:37 UTC
(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
Comment 18 Lionel Landwerlin 2019-09-02 14:53:35 UTC
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?
Comment 19 Stanislav Lisovskiy 2019-09-03 07:05:50 UTC
(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.
Comment 20 Lionel Landwerlin 2019-09-03 07:14:42 UTC
(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?
Comment 21 Stanislav Lisovskiy 2019-09-03 07:28:08 UTC
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.
Comment 22 Lionel Landwerlin 2019-09-03 07:33:25 UTC
(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?
Comment 23 Stanislav Lisovskiy 2019-09-03 07:35:59 UTC
(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?
Comment 24 Lionel Landwerlin 2019-09-03 17:57:35 UTC
(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.
Comment 25 Lionel Landwerlin 2019-09-03 19:42:47 UTC
(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.
Comment 26 Stanislav Lisovskiy 2019-09-04 06:59:27 UTC
(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.
Comment 27 Lionel Landwerlin 2019-09-04 07:39:04 UTC
(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.
Comment 28 Stanislav Lisovskiy 2019-09-04 09:27:08 UTC
> 
> 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.
Comment 29 Lionel Landwerlin 2019-09-04 09:38:46 UTC
(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.
Comment 30 Lionel Landwerlin 2019-09-04 21:05:44 UTC
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.
Comment 31 Stanislav Lisovskiy 2019-09-05 07:18:41 UTC
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.
Comment 32 Lionel Landwerlin 2019-09-10 08:55:37 UTC
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...
Comment 33 Stanislav Lisovskiy 2019-09-12 08:19:36 UTC
(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.
Comment 34 Lionel Landwerlin 2019-09-12 08:26:06 UTC
(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.
Comment 35 Lionel Landwerlin 2019-09-12 08:34:37 UTC
(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.
Comment 36 Stanislav Lisovskiy 2019-09-12 13:44:09 UTC
(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?
Comment 37 Lionel Landwerlin 2019-09-12 13:50:34 UTC
(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).
Comment 38 Lionel Landwerlin 2019-09-17 14:03:49 UTC
Not able to reproduce anymore. Should we close?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.