Additional data point: same leak on amdgpu, and it does NOT require the screen
to be blanked or the session locked.
Hardware / software
-------------------
Ubuntu 24.04.5 LTS, Wayland
kernel 7.0.0-31-generic
gnome-shell 46.0-0ubuntu6~24.04.14
mutter 46.2-1ubuntu0.24.04.16
mesa 25.2.8-0ubuntu0.24.04.2
AMD GPU [1002:7551], 32624 MB VRAM, ASUS ProArt X870E-CREATOR WIFI, Ryzen 9
9950X, 64 GB RAM
Displays: DP-1 Samsung LS27AG30x 1920x1080@144 (connector_id 431)
DP-2 Dell P2217H 1920x1080@60 (connector_id 441)
What is different from the existing reports
-------------------------------------------
This bug is currently titled [i915] and most comments describe the leak starting
when the session locks and the display goes DPMS-off. On this machine the leak
runs continuously with both monitors powered on and the user actively working:
vram_used: 24924 MB -> 25011 MB over 24 s (+86 MB, screen on,
session active)
gnome-shell owns essentially all of it (per-process DRM fdinfo):
gnome-shell (pid 6303): 24902 MB vram, 12 MB gtt
Xwayland: 18 MB vram
gsd-xsettings: 12 MB vram
mutter-x11-frames: 12 MB vram
Trigger identified
------------------
The kernel emits a DRM hotplug uevent for one specific connector, in pairs,
every 12.38 s, indefinitely, with no user action:
KERNEL[7221.319] change /devices/.../drm/card1 (drm)
ACTION=change HOTPLUG=1 CONNECTOR=431 DEVNAME=/dev/dri/card1
KERNEL[7221.672] change (second of the pair, +0.35 s)
KERNEL[7233.698] change (next pair, +12.38 s)
connector_id 431 is DP-1, the Samsung panel. Polling
/sys/class/drm/card1-DP-1/status intermittently returns "disconnected" while the
picture never actually drops, i.e. the panel is flapping its HPD line. DP-2 is
stable. This matches the "MonitorsChanged in pairs" behaviour described in
comment #25, but here the pairs are driven by real hotplug uevents rather than
by
DPMS-off, which is why blanking is not required to reproduce it.
VRAM rises in exact 39 MB steps, one step per uevent pair, nothing in
between:
22:50:18 22020 MB
22:50:30 22059 MB +39
22:50:42 22098 MB +39
Why this is easy to misdiagnose
-------------------------------
Before I capped ttm.pages_limit, the leak did not land in VRAM at all. It went
into system RAM through GTT, where it is invisible to every per-process counter.
At the OOM that killed my session, all 284 processes together held 1059 MB RSS
while shmem held 28746 MB owned by nothing, and all 32 GB of swap was full.
mem_info_vram_used read 333 MB at the time, so the card looked idle.
Setting ttm.pages_limit=2097152 (8 GiB, matching GTT) bounds the damage and
makes
the leak visible in VRAM instead, where fdinfo attributes it correctly to
gnome-shell. The distro default is half of system RAM, 8181797 pages / 31960 MB
on a 64 GB machine, which is enough for this leak to take the machine down.
Other notes
-----------
- MUTTER_DEBUG_DISABLE_HW_CURSOR=1 silenced the
"Cursor update failed: drmModeAtomicCommit: Invalid argument" messages but did
not slow the leak at all.
- Fills the card's 32 GB in roughly four hours from a clean login.
- Happens identically on the GDM greeter with no user logged in, so it is not
extension or application related. Enabled extensions are only ding,
ubuntu-dock and tiling-assistant.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2143073
Title:
[i915] ShmemHugePages leak during GNOME lock screen
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2143073/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
