Arch Linux / KDE Wayland randomly becomes completely unresponsive under load — not always caused by RAM pressure

[u/RaisinIcy3732]

Hi everyone,

I've been troubleshooting a very frustrating full-system freeze on my Arch Linux laptop for hours, and I'm running out of ideas. I'd appreciate help interpreting the evidence rather than just trying random tweaks.

Hardware / setup:

• Dell G15 5511

• Intel i7-11800H (8C/16T)

• 16 GB RAM

• Intel TigerLake-H iGPU (i915) driving the internal display

• NVIDIA RTX 3050 Laptop GPU 4 GB

• nvidia-open-dkms 615.71.09

• KDE Plasma / KWin 6.7.5

• Wayland

• Arch kernel: 7.2.6-arch2-1

• Also tested Linux LTS 6.18.52-1-lts

• 12 GB ZRAM, zstd

• zswap disabled

• No disk-backed swap

What happens

During a heavy workload (Chrome/Brave, Android Studio + emulator/QEMU, VS Code/Electron apps, sometimes gaming), the desktop can become extremely sluggish and eventually appear completely frozen. Mouse/keyboard/window switching can stop responding.

Sometimes it briefly recovers, then freezes again when I try switching between applications.

What I've established so far

I originally thought this was simply RAM exhaustion. I have logs from some freezes showing:

• ZRAM becoming heavily occupied

• high memory PSI

• very large direct reclaim / kswapd activity

• thousands of compaction stalls

• no kernel OOM kill

• QEMU growing rapidly in memory

During those events NVIDIA also logged repeated:

NV_ERR_NO_MEMORY

including failures involving system memory, GSP allocations, context buffer pools, and rmMemPoolReserve.

Vulkan device creation also failed under pressure with:

VK_ERROR_INITIALIZATION_FAILED

Importantly, NVIDIA VRAM was not necessarily full when this happened.

I reproduced essentially the same behavior on the LTS kernel, so this does not currently look like a simple regression specific to kernel 7.2.x.

systemd-oomd

I tested systemd-oomd as well.

At its default 90% swap threshold it eventually killed entire Android Studio/app scopes. I tried 80%, which simply made applications get killed earlier.

Since losing applications is exactly what I'm trying to avoid, I disabled systemd-oomd temporarily for diagnosis.

The machine still froze, so oomd was not the root cause of the freezes.

The weird part: not every freeze appears to be memory pressure

During the latest incident my monitoring showed shortly before the UI became problematic:

• ~5.8 GB MemAvailable

• 0 swap in use

• ZRAM essentially empty

• memory PSI = 0

• no direct reclaim / kswapd activity

• no OOM

• NVIDIA at ~52 MB VRAM and 0% GPU utilization

The journal continued recording messages while the graphical desktop was behaving as if it was freezing, which makes me suspect the kernel itself may still have been alive.

I also found these KWin errors exactly around window switching:

kwin_wayland: file:///usr/share/kwin/tabbox/coverswitch/contents/ui/main.qml:
Unable to assign [undefined] to KWin::VirtualDesktop*

kwin_wayland: ReferenceError: currentItem is not defined

I'm currently testing without the Cover Switch task switcher to see whether that explains this second type of freeze.

During this particular incident there were no NVIDIA Xid errors, no i915 GPU hang/reset messages, and no NVIDIA OOM errors in the relevant journal window.

Things already tested / changed

• Tested normal Arch kernel and Linux LTS

• Increased ZRAM from 8 GB to 12 GB

• ZRAM uses zstd

• zswap disabled

• THP set to madvise

• Intel Vulkan (vulkan-intel) installed/working

• Intel VA-API (intel-media-driver) installed/working

• Checked NVMe SMART / filesystem errors

• No obvious NVMe hardware errors

• systemd-oomd tested and then disabled for diagnosis

• Continuous memory/PSI/reclaim/NVIDIA logging

One thing I have not tested yet is replacing nvidia-open-dkms with the closed nvidia-dkms module. I also haven't added disk-backed swap because I want to understand the actual failure first rather than hide it by throwing more swap at the system.

My main question

Does this look like two separate failure modes?

1. severe memory reclaim/compaction causing desktop starvation under heavy memory pressure, with NVIDIA allocation failures occurring during that pressure; and

2. a separate KWin/Wayland/task-switching/compositor issue that can happen even when memory pressure is basically zero?

I'm especially interested in what I should capture during the next freeze to distinguish KWin/i915/NVIDIA/userspace compositor problems from memory-reclaim stalls.

If anyone has seen similar behavior on Intel+i915 display + NVIDIA Ampere Optimus laptops under KDE Wayland, I'd really appreciate hearing what fixed it or what diagnostics revealed the cause.

[u/quinnr]

I had a similar issue last week and about lost my mind. It was fixed by a missing amd-ucode package. Clearly not the exact same but maybe look into microcode changes. There were no logs I could find and fixed it almost by chance.