Bug 109675 - Screens reorganise, failed to enable link training errors in dmesg about 60s after plugging in dock
Summary: Screens reorganise, failed to enable link training errors in dmesg about 60s ...
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-19 10:05 UTC by Shaun
Modified: 2019-11-29 18:08 UTC (History)
2 users (show)

See Also:
i915 platform: CFL
i915 features: display/DP

Attachments
Full dmesg since boot with drm.debug=0xe (252.46 KB, text/plain)
2019-02-19 10:13 UTC, Shaun 		no flags Details
xrandr --verbose (36.01 KB, text/x-log)
2019-02-19 10:14 UTC, Shaun 		no flags Details
lshw output (32.44 KB, text/plain)
2019-02-19 10:19 UTC, Shaun 		no flags Details
Full dmesg since boot with drm.debug=0xe (from kern.log) (1.10 MB, text/x-log)
2019-02-19 11:07 UTC, Shaun 		no flags Details
Show Obsolete (1) View All

Description Shaun 2019-02-19 10:05:57 UTC 
I have a Dell Precision 5530 and a Dell TB16 dock.  Either when I first log in with dock already connected, or when I plug in the dock with external screen connected over (mini) display port, initially, within about a second the screen fires up and works as expected with the correct screen layout as previously configured.  Then, after about 60s of normal behaviour, the screens suddenly reorganise 2-3 times, with the displays swapping, then showing garbage (half a screen with black across the other half, magnified) then eventually they usually settle down to the correct orientation again.  This dance takes about 60s.

At the same time as the screen re-org, I see the following errors in dmesg and my USB devices attached to the dock sometimes disconnect at that time too:

[  110.409017] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
[  110.678752] [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
[  113.561585] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
[  113.829922] [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi


I'm on Ubuntu, using UKUU to install the mainline kernel.  Most recent available at time of writing is 4.20.10, behaviour seems consistent with 4.20.x.  Earlier versions had other issues with this dock.
Comment 1 Shaun 2019-02-19 10:13:51 UTC 
Created attachment 143405 [details]
Full dmesg since boot with drm.debug=0xe

Captured a full dmesg with debug.  Looks like the action kicks off at this point after a 60s gap consisting of only drm:drm_mode_addfb2 messages:

[   91.442369] [drm:intel_get_hpd_pins.isra.13 [i915]] hotplug event received, stat 0x00400000, dig 0x10101210, pins 0x00000040, long 0x00000040
Comment 2 Shaun 2019-02-19 10:14:41 UTC 
Created attachment 143406 [details]
xrandr --verbose
Comment 3 Shaun 2019-02-19 10:18:28 UTC 
$ uname -a
Linux shauns-laptop 4.20.10-042010-generic #201902150516 SMP Fri Feb 15 10:19:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

xorg version: 1:7.7+19ubuntu8
Comment 4 Shaun 2019-02-19 10:19:01 UTC 
Created attachment 143407 [details]
lshw output
Comment 5 Lakshmi 2019-02-19 10:22:54 UTC 
(In reply to Shaun from comment #1)
> Created attachment 143405 [details]
> Full dmesg since boot with drm.debug=0xe
> 
> Captured a full dmesg with debug.  Looks like the action kicks off at this
> point after a 60s gap consisting of only drm:drm_mode_addfb2 messages:
> 
> [   91.442369] [drm:intel_get_hpd_pins.isra.13 [i915]] hotplug event
> received, stat 0x00400000, dig 0x10101210, pins 0x00000040, long 0x00000040

Shaun, Can you attach full dmesg from boot.

@Manasi can you help here with the existing logs?
Comment 6 Shaun 2019-02-19 10:29:23 UTC 
Yes, done. I also added xranadr and lshw output in code that's useful.
Comment 7 Shaun 2019-02-19 11:07:32 UTC 
Created attachment 143408 [details]
Full dmesg since boot with drm.debug=0xe (from kern.log)

Sorry, now I see why you asked.  I didn't realise the log I uploaded was truncated.  Looks like the same output was in kern.log
Comment 8 Mario Limonciello 2019-03-25 18:48:08 UTC 
Would you please try to modify /etc/fwupd/daemon.conf to blacklist the dell plugin and reboot the machine?  If that avoids this issue then I suspect it's this:

https://github.com/hughsie/fwupd/issues/1105
https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1806323
https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1793965

Which I do feel is an i915 bug.
Comment 9 Shaun 2019-03-26 10:51:18 UTC 
Confirmed: after adding dell to the fwupdmgr modules blacklist, plugging in my dock no longer causes a screen shuffle.
Comment 10 Lakshmi 2019-07-17 07:35:47 UTC 
@Manasi, any suggestions from your side to this issue?
Comment 11 Manasi 2019-07-29 20:14:07 UTC 
Looking at the logs, I feel that just before the seeing the aux timeouts in inte_mst_pre_enable_dp(), after we call drm_dp_send_power_updown_phy to power up the port its probably not powering up yet, we need to check the ret of that call and keep calling until it succeeds before proceeding with link training.

Manasi
Comment 12 Manasi 2019-07-29 20:17:03 UTC 
Also is it possible to upgrade your kernel on ubuntu to more recent kernel from drm-tip?

The call drm_dp_send_power_updown_phy() might not even be present for 4.20 kernel and this might actually be the issue.

Manasi
Comment 13 Martin Peres 2019-11-29 18:08:32 UTC 
-- 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/233.

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.