Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
Project 'drm/intel' was moved to 'drm/i915/kernel'. Please update any links and bookmarks that may still have the old path.
Attached the DMSG files on kernel 6.8.0-rc2-gc55498db0a43. With the patch, HPD detects main link status and do retraining the main link for the main link lost.
@gyu3 , @wonkandy , could you please give a try to the latest drm-tip kernel and provide a dmesg log after booting with drm.debug=0x10e and the steps to reproduce the problem? Thanks.
Does the external monitor get enabled ok right after you plug in the dock and before you switch to mirror mode?
Could you reproduce the issue with the same sequence making sure you have CONFIG_DRM_DISPLAY_DP_AUX_CHARDEV enabled in your kconfig and booting with log_buf_len=20M drm.debug=0x15e marking the plugin-dock/switch-to-mirror-mode/issue-found events to syslog as you did before and also marking the moment where the external monitor still displays okay after the plugin-dock event?
After the whole sequence where you see the issue (I assume sometime after the switch-to-mirror-mode event), please do:
where the actual drm_dp_auxD file can be looked up under /sys/class/drm/card0-DP-1 and provide the the above aux-*.log's and the system log? Please make sure that the system log contains all the kernel messages starting from boot-up.
@gyu3 , thanks. After the dock is plugged at point 3. the external monitor is modeset, link training passing at:
[ 199.086704] i915 0000:00:02.0: [drm:intel_dp_link_train_phy] [CONNECTOR:194:DP-1][ENCODER:193:DDI TC1/PHY TC1][LTTPR 1] Link Training passed at link rate = 810000, lane count = 2[ 199.133271] i915 0000:00:02.0: [drm:intel_dp_link_train_phy] [CONNECTOR:194:DP-1][ENCODER:193:DDI TC1/PHY TC1][DPRX] Link Training passed at link rate = 810000, lane count = 2
After 2 sec the MST link goes bad and is recovered at: (*)
[ 201.175463] i915 0000:00:02.0: [drm:intel_dp_link_check_work_fn] [ENCODER:193:DDI TC1/PHY TC1] retraining link (forced no)[ 201.381924] i915 0000:00:02.0: [drm:intel_dp_link_train_phy] [CONNECTOR:194:DP-1][ENCODER:193:DDI TC1/PHY TC1][LTTPR 1] Link Training passed at link rate = 810000, lane count = 2[ 201.427589] i915 0000:00:02.0: [drm:intel_dp_link_train_phy] [CONNECTOR:194:DP-1][ENCODER:193:DDI TC1/PHY TC1][DPRX] Link Training passed at link rate = 810000, lane count = 2
Things are okay for more than a minute and then after switching to mirror mode, the MST link goes bad again:
[ 529.084742] i915 0000:00:02.0: [drm:drm_dp_dpcd_read] AUX USBC1/DDI TC1/PHY TC1: 0x00202 AUX -> (ret= 1) 00
This is strange, since neither the eDP or the MST output is modeset at all after (*) above. There is a modeset commit for eDP at:
[ 306.941068] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CRTC:80:pipe A] mode changed...[ 306.941295] i915 0000:00:02.0: [drm:pipe_config_mismatch] [CRTC:80:pipe A] fastset requirement not met in hw.pipe_mode.crtc_clock (expected 76890, found 61520)...[ 306.941313] i915 0000:00:02.0: [drm:intel_atomic_check] fastset requirement not met, forcing full modeset
but this doesn't result in an actual modeset (disabling/re-enabling the eDP link). Maybe this is just a TEST_ONLY commit. Other than that I see planes getting turned on/off on the eDP output, but this shouldn't affect the MST link either.
@gyu3 , could you try if with the latest drm-tip kernel the issue reproduces with the same sequence?
Meanwhile, can you please review the changes in the description of this issue? We have investigated the case and confirm that the link lost happens with the particular docker. The docker assert HPD once the link lost are detected. The trace are attached.
Thanks for the testing and logs. The kernel you used is not the latest drm-tip branch from [1], could you please provide the same dmesg+aux logs using that kernel with the same kernel parameters, also adding the 'logger -s' markers at the moment the display is still ok and immediately after you notice it goes bad? For the aux logs it's enough to dump the registers from the aux1 device (no need for aux5).
Also, please make sure that both the host's BIOS version and the dock's FW version is up-to-date. You can use fwupdmgr for instance to check these.
UD22 docker is attached. Boot to Ubuntu 23.10 with drm-tip 6.10.0-rc5-ga6c75685695a. The steps can be different from the previous one but the causes are the same.
Steps for the logs are
Reboot DUT. After log on system by an user, eDP showed the extended screen and external HDMI showed nothing. The expectation is both display are in mirror mode. The tag in syslog is
================= Reboot to desktop. HDMI shows nothing and eDP shows extended screen. The expectation is in mirror mode ================
and the prefix of the log file names is ng-.
Continue step 1, switch display mode by "super key + p key" several times, the external HDMI showed the same picture as eDP in mirror mode. The tag in syslog is
================= Switch several times between mirror, extended, external only, build-in only. HDMI and eDP show the same picture ================
and the prefix of the log file names is good-.
The firmware versions are in firmware-version. They are up to date.
Thanks. Could you give a try on this same kernel using the same kernel parameters to 0001-drm-i915-dp_mst-Check-link-status.patch
and provide a syslog? No need for the AUX logs any more, but please still add the good/not-good 'syslog -s' markers. Thanks.
Thanks for the testing and the logs. So the above change would be enough to detect a bad link and retrain the link. However it's still odd that the link goes bad semi-randomly. Could you still give a try to another patch in addition to the above one, so both of the following two applied on drm-tip, and provide a dmesg log with that? :
sudo sh -c 'cat /dev/null > /var/log/syslog' && sudo reboot
sudo logger -s "================= Reboot to desktop. eDP shows the main screen and HDMI shows the extended screen. This is good. ================"
sudo logger -s "================= Switch display modes by "super key" + "P key". Both eDP and HDMI 4. show the correct picture. This is good. ================"
Ok, thanks for the testing and the logs. In syslog-0703 I can't see the link state going bad unexpectedly requiring a link retrain any more, so looks like the root cause for the issue was switching the LTTPR mode while the link is active. The above 0002-drm-i915-dp-Don-t-switch-LTTPR-mode-on-an-active-lin.patch is enough to fix that so I'll send that for review with a slight change.
commit 211ad49cf8ccfdc798a719b4d1e000d0a8a9e588Author: Imre Deak <imre.deak@intel.com>Date: Mon Jul 8 22:00:25 2024 +0300 drm/i915/dp: Don't switch the LTTPR mode on an active link
now merged to drm-tip. Thanks for the report, testing and logs.