Public bug reported:
Source package: linux-signed-hwe-6.17
Ubuntu release: 24.04.4 LTS (`lsb_release -rd`)
Package version: linux-image-6.17.0-35-generic 6.17.0-35.35~24.04.1 (`apt-cache
policy linux-image-6.17.0-35-generic`)
Expected: resuming from suspend/s2idle while docked to an external monitor via
DP-MST should restore the display normally.
Actual: the display pipeline is corrupted on resume — either the desktop
becomes unresponsive (mouse cursor still moves, no redraws) or the screen goes
fully black with no video output. Only a full display-manager restart
(`systemctl restart sddm`) recovers it; re-plugging the dock does not.
Summary:
On a Dell Precision 5690 (Meteor Lake, hybrid Intel Arc + NVIDIA RTX 4000 Ada),
resuming from suspend while connected to an external monitor via DisplayPort
Multi-Stream Transport (MST) reliably corrupts the display pipeline. Symptoms
range from the desktop becoming unresponsive (mouse cursor still moves, no
redraws) to a fully black screen with no video output at all. The only
recovery I have found is restarting the display manager (`systemctl restart
sddm`), which forces a fresh X server and re-probes the MST topology from
scratch; re-plugging the dock does not help once the pipeline is wedged.
I hit this twice in one day, with two different docks and two different
trigger paths, both producing distinct kernel-side faults in the same area of
drivers/gpu/drm/display/drm_dp_mst_topology.c. I think that rules out a bad
cable/dock as the root cause and points at the MST resume/reprobe path itself.
Hardware: Dell Precision 5690, BIOS 1.23.0 (2026-04-23)
Kernel: 6.17.0-35-generic (source package linux-signed-hwe-6.17)
GPU: Intel Arc (Meteor Lake iGPU, i915) + NVIDIA RTX 4000 Ada Generation,
hybrid/PRIME, nvidia-driver-595-open 595.71.05
Xorg: xserver-xorg-core 2:21.1.12-1ubuntu1.6
--- Incident 1 (real suspend, ~6h20m, Thunderbolt dock + 2 external
monitors) ---
Suspended (s2idle) at 00:38:10 (user-initiated, no lid event involved). Resumed
on lid-open at 06:58:59 after ~6h20m asleep. The OS-level resume itself
completed cleanly, but ~2.5 minutes later, when Xorg issued a DPMS-on / modeset
enable to actually light the displays, the kernel produced:
i915 0000:00:02.0: [drm] drm_WARN_ON(!mgr->mst_state || !mgr->mst_primary)
WARNING: CPU: 3 PID: 3871 at
drivers/gpu/drm/display/drm_dp_mst_topology.c:3741
drm_dp_mst_topology_queue_probe+0xdb/0xe0 [drm_display_helper]
Call Trace:
mst_stream_pre_enable+0x216/0x2e0 [i915]
intel_encoders_pre_enable+0x82/0xb0 [i915]
hsw_crtc_enable+0x128/0x5b0 [i915]
intel_enable_crtc+0x118/0x150 [i915]
skl_commit_modeset_enables+0x3a2/0x720 [i915]
intel_atomic_commit_tail+0x652/0xc70 [i915]
intel_atomic_commit+0x2b3/0x300 [i915]
drm_atomic_commit+0xac/0xf0
drm_atomic_connector_commit_dpms+0xfc/0x110
drm_mode_obj_set_property_ioctl+0x1c3/0x450
...
Every display stayed black from that point on. Recovered only via
`sudo systemctl restart sddm`.
--- Incident 2 (spurious ~85ms micro-suspend, same day, Dell P2724DEB
monitor's built-in USB-C hub, 1 external monitor) ---
While actively using the machine (lid open), logind logged an unexplained
"Lid closed." at 09:40:09.412 and immediately began a real suspend. KDE's
powerdevil tried to veto it ("Lid action was suppressed because an external
monitor is present") but the veto landed 3ms after the kernel had already
started freezing tasks — the suspend proceeded and the system resumed itself
about 85ms later. (I'm filing the spurious lid event as a separate open
question — possibly EC/ACPI-side — this report is about what the resume did
to the display pipeline, which is reproducible regardless of why the resume
happened.)
During that resume's atomic modeset restore, the kernel hit:
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in
drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36
shift exponent -1 is negative
Call Trace:
drm_dp_atomic_release_time_slots.cold+0x17/0x3d [drm_display_helper]
mst_connector_atomic_check+0x169/0x190 [i915]
drm_atomic_helper_check_modeset+0x308/0x740
intel_atomic_check+0x10d/0xaf0 [i915]
drm_atomic_check_only+0x1a1/0x400
drm_atomic_commit+0x6e/0xf0
drm_client_modeset_commit_atomic+0x1fe/0x240
drm_client_modeset_commit_locked+0x5b/0x170
drm_client_modeset_commit+0x26/0x50
__drm_fb_helper_restore_fbdev_mode_unlocked+0xd7/0x100
drm_fb_helper_hotplug_event+0x10b/0x120
drm_fbdev_client_hotplug+0x28/0xd0
drm_client_hotplug+0x5f/0xd0
drm_client_dev_resume+0xdf/0x120
i915_drm_resume+0x190/0x200 [i915]
i915_pm_resume+0x1b/0x30 [i915]
pci_pm_resume+0x72/0x110
...
This time the fault is on the kernel's own resume path (not triggered by
Xorg), which suggests the MST topology manager's time-slot/bandwidth
bookkeeping doesn't survive a suspend/resume transition full stop, whether
the sleep lasts 6 hours or 85 milliseconds.
The desktop became unresponsive immediately after (mouse cursor still moved —
consistent with the hardware cursor plane not needing a full atomic commit —
but no redraws happened). I unplugged/replugged the dock three times over the
next several minutes trying to recover it; each replug fully re-enumerated
the dock's USB tree but Xorg never logged any attempt to handle the hotplug
(confirmed via /var/log/Xorg.0.log — no activity at all between the freeze
and the eventual display-manager restart), so it was already wedged past the
point of self-recovery. It progressed to a fully black screen. Recovered
again only via `sudo systemctl restart sddm`.
--- Why I don't think this is a local misconfiguration ---
- Both crashes are in stock in-tree drm_display_helper/i915 code, not in any
of the out-of-tree modules this system has loaded (nvidia/nvidia_uvm/
nvidia_drm/nvidia_modeset, intel_ipu6_psys, ov02e10, v4l2loopback — all
tainted (O) but none appear in either backtrace).
- TLP's USB-autosuspend and PCIe-ASPM settings are untouched defaults; no
custom systemd-sleep hooks are installed beyond the vendor-shipped
nvidia/tlp/unattended-upgrades ones.
- Two different physical docks (a Thunderbolt dock at home, a monitor's
built-in USB-C hub at the office) both reproduced a suspend/resume MST
wedge on the same day, which argues against one bad cable/dock/hub.
--- Ask ---
Could someone familiar with drm_dp_mst_topology.c take a look at whether
mst_state/mst_primary and the time-slot accounting in
drm_dp_atomic_release_time_slots are correctly re-initialized across a
suspend/resume cycle when an MST branch device is attached at both suspend
and resume? Happy to provide more logs, test patches, or attempt reproduction
with instrumentation if useful.
--- Disclosure ---
The kernel is tainted (O) due to out-of-tree DKMS modules unrelated to
graphics (camera drivers, v4l2loopback) and the NVIDIA proprietary/open
driver used for hybrid PRIME offload. I'm flagging this proactively since I
know tainted-kernel reports are sometimes deprioritized — happy to attempt a
reproduction with those modules unloaded if that would help triage, though
the crash site itself is in stock i915/drm code neither module family
touches.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: linux-image-6.17.0-35-generic 6.17.0-35.35~24.04.1
ProcVersionSignature: Ubuntu 6.17.0-35.35~24.04.1-generic 6.17.13
Uname: Linux 6.17.0-35-generic x86_64
ApportVersion: 2.28.2-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Mon Jul 13 15:37:51 2026
InstallationDate: Installed on 2024-10-22 (629 days ago)
InstallationMedia: Kubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240425.1)
MachineType: Dell Inc. Precision 5690
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-35-generic
root=UUID=f06237b6-ac5a-48e0-a5ae-74a6c81d5872 ro quiet splash
nvidia.NVreg_PreserveVideoMemoryAllocations=1 vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No
PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
linux-restricted-modules-6.17.0-35-generic N/A
linux-backports-modules-6.17.0-35-generic N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.27
SourcePackage: linux-hwe-6.17
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/23/2026
dmi.bios.release: 1.23
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.23.0
dmi.board.name: 088TDK
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.ec.firmware.release: 1.24
dmi.modalias:
dmi:bvnDellInc.:bvr1.23.0:bd04/23/2026:br1.23:efr1.24:svnDellInc.:pnPrecision5690:pvr:rvnDellInc.:rn088TDK:rvrA00:cvnDellInc.:ct10:cvr:sku0CC8:
dmi.product.family: Precision
dmi.product.name: Precision 5690
dmi.product.sku: 0CC8
dmi.sys.vendor: Dell Inc.
** Affects: linux-hwe-6.17 (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug noble
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160532
Title:
Display pipeline wedges after suspend/resume while docked via DP-MST —
two distinct crashes in i915/drm_display_helper, kernel-tainted-clean
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.17/+bug/2160532/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
