Additional data point: same failure on Lunar Lake with the generic HWE kernel
(not linux-oem), which may widen the scope of this bug beyond Arrow Lake / OEM.
SYSTEM
GPU: Intel Lunar Lake [8086:64a0] rev 04, xe driver
Kernel: 7.0.0-28-generic (linux-image-generic-hwe-24.04), Ubuntu 24.04
Session: GNOME 46, Wayland
mutter: 46.2-1ubuntu0.24.04.16 (also reproduced on .14)
gnome-shell: 46.0-0ubuntu6~24.04.14
Displays: eDP-1 (internal) + external over a Type-C link, enumerating as
DP-1 and HDMI-A-1
SUMMARY
Two full memory-exhaustion events in a week, both ending with the machine
unusable. Both are preceded by a continuous display hot-plug-detect storm, and
in both cases the exhausted memory is invisible to the OOM killer, exactly as
described for the xe driver in this bug.
TRIGGER - CONTINUOUS HPD STORM
The kernel reports workqueue counters at doubling thresholds, so these show a
storm running for ~7 hours straight, beginning 7 seconds after boot:
22:13:34 i915_hotplug_work_func [xe] hogged CPU >10000us 4 times
22:26:36 i915_hpd_poll_init_work [xe] hogged CPU >10000us 4 times
22:46:36 i915_hpd_poll_init_work [xe] hogged CPU >10000us 131 times
23:27:53 i915_hotplug_work_func [xe] hogged CPU >10000us 131 times
00:16:09 i915_hotplug_work_func [xe] hogged CPU >10000us 259 times
01:38:43 i915_hotplug_work_func [xe] hogged CPU >10000us 515 times
04:28:39 i915_hpd_poll_init_work [xe] hogged CPU >10000us 2051 times
04:52:10 i915_hotplug_work_func [xe] hogged CPU >10000us 1027 times
output_poll_execute tracks alongside, reaching 1027 by 03:58.
RESULT - OOM WITH NOTHING RECLAIMABLE
01:07:00 first gnome-shell page allocation failure
01:07:29 first OOM kill
05:16:52 system dead
34 OOM kills total
The allocation failures come from the xe/TTM path:
ttm_pool_alloc_page -> __ttm_pool_alloc -> ttm_pool_restore_and_alloc
-> ttm_tt_restore -> xe_ttm_tt_populate [xe] -> ttm_tt_populate
-> ttm_bo_populate -> ttm_bo_handle_move_mem -> ttm_bo_validate
-> xe_bo_validate [xe] -> xe_gpuvm_validate [xe]
-> drm_gpuvm_validate [drm_gpuvm] -> xe_vm_validate_rebind [xe]
-> xe_exec_fn [xe] -> xe_validation_exec_lock [xe]
-> xe_exec_ioctl [xe] -> drm_ioctl -> xe_drm_ioctl [xe]
The decisive evidence that the leaked memory is driver-owned and unreclaimable:
parsing the OOM killer's own task dump gives
400 processes, COMBINED RSS 9.7 MiB
largest single process: tracker-miner-f at 516 KiB
on a 30 GiB machine. Summing the kernel's Mem-Info accounts for roughly 3.4 GB
of ~33 GB; about 30 GB is held by no process. The OOM killer destroyed 34
processes holding a combined ~10 MiB and freed nothing, because the memory is
exported DMA-BUF/TTM objects rather than process RSS.
CMA DETAIL
Free memory looked healthy but was almost entirely CMA, unusable for the
GFP_KERNEL allocations that were failing:
Node 0 Normal free:2665176kB free_cma:2601284kB min:64564kB
Usable non-CMA free was 63,892 kB against a 64,564 kB watermark - i.e. sitting
exactly on the OOM boundary while appearing to have 2.6 GB free. The zone was
flagged all_unreclaimable? yes.
LEAK CONTINUES AFTER SESSION DEATH
The user session died mid-event and gnome-shell restarted under UID 120 (gdm).
It kept leaking on the login greeter until the machine was gone:
03:08 Xwayland crashed (/var/crash/_usr_bin_Xwayland.120.crash)
05:14:30 page allocation failure, Comm: gnome-shell, UID: 120
05:16:52 dead
BASELINE FOR COMPARISON
On a healthy boot, gnome-shell holds a steady ~390 MiB:
$ grep -h drm-total-gtt /proc/$(pgrep -x gnome-shell)/fdinfo/* | sort -u
drm-total-gtt: 397940 KiB
drm-driver: xe
NOTES
The external display link is independently suspect: the same boot logged
xe 0000:00:02.0: [drm] TC PLL 3: pll hw state mismatch
WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945
at verify_single_dpll_state+0x6c7/0x7e0 [xe]
and the external output's preferred mode has changed between boots (3440x1440
vs 1920x1080), suggesting the link is renegotiating. This is consistent with
the report that external monitors with unreliable connections are the strongest
trigger - but note the leak's consequence here is far more severe than a slow
lock-screen leak, because the HPD storm runs continuously rather than only
during DPMS-off.
Happy to supply full journals or test a patch.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-shell in Ubuntu.
https://bugs.launchpad.net/bugs/2143073
Title:
ShmemHugePages leak during GNOME lock screen on 6.17.0-1012-oem causes
OOM
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2143073/+subscriptions
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
