DisplayPort link training fails after a modeset · Linux Fix Lab

Symptoms & scope

Monitor shows no signal after changing resolution or refresh rate.
An output repeatedly reconnects although the connector remains detected.

Relevant environment

DisplayPort outputs, especially high refresh rates, docks, MST hubs or adapters. Recovery behavior depends on the driver and kernel version.

Recognizable messages (synthetic examples)

i915 0000:00:02.0: [drm] [CONNECTOR:95:DP-1][DPRX] Link Training failed at link rate = 270000, lane count = 4

Inspect timing and physical path; logs differ by driver, so this narrow literal signature cannot cover every DisplayPort failure.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

Insufficient link margin, cable quality or intermediary bandwidth limits can prevent training.
Driver, monitor firmware or dock firmware may fail to recover a link; EDID detection alone does not test link stability.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read DisplayPort events in the affected boot; access may require an administrator and some drivers log detail only with debug enabled.

journalctl -b -k --no-pager --grep='link training|Link Training|DP-'

Interpret the result: Training failure near the modeset supports a link-path investigation. A scheduler ring timeout belongs to a different failure mechanism.

Check 2

Replace card0-DP-1 with the affected DRM connector. Both sysfs files are read-only; modes lists available sizes, not every refresh timing.

cat /sys/class/drm/card0-DP-1/status /sys/class/drm/card0-DP-1/modes

Interpret the result: connected means a sink is detected, not that its current link carries a valid image. Compare with the desktop’s exact selected timing.

Evidence-guided next steps

Test a lower-bandwidth display mode

If failure occurs only at a high-bandwidth mode, select a supported lower refresh rate or resolution in display settings and compare. If stable, inspect cable/dock capabilities and any HDR or multi-monitor bandwidth demands separately.

Precautions: Use a timed display-settings confirmation and keep a second console available. Lower bandwidth is a diagnostic comparison, not proof that the monitor is defective.

Recovery / rollback: Reject the confirmation or restore the original supported mode if the test loses output.

Did this solution help you?

Share this solution #

Isolate the DisplayPort connection path

If the lower-bandwidth comparison implicates the path, bypass the dock, MST hub or adapter and use a suitable direct cable. Apply vendor-provided monitor or dock firmware only if its release notes match the problem.

Precautions: Record the initial layout and firmware versions. Do not use debugfs fault injection or write link registers as an end-user workaround.

Recovery / rollback: Reconnect the documented original layout; use the vendor’s supported firmware recovery path if an update fails.