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.
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
Created attachment 143406 [details]
$ 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
Created attachment 143407 [details]
(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?
Yes, done. I also added xranadr and lshw output in code that's useful.
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
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:
Which I do feel is an i915 bug.
Confirmed: after adding dell to the fwupdmgr modules blacklist, plugging in my dock no longer causes a screen shuffle.
@Manasi, any suggestions from your side to this issue?
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.
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.
-- 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.