Dear Maintainer, Subject: i915 kernel BUG when freeing GEM object (Xorg, xfwm4 compositor, hard lock) Package: src:linux Version: 6.12.94-1 Severity: important Hi, I’m seeing reproducible hard lockups on Debian 13 (trixie) with the stock 6.12.94+deb13-amd64 kernel when running Xfce with the Xfwm4 compositor enabled on a System76 Serval WS laptop (Intel iGPU + NVIDIA dGPU). Symptom ======= Roughly once per session (sometimes more), the system suddenly freezes: - The *mouse cursor still moves* on screen. - *Keyboard input stops working completely* (no response to any keys, including Ctrl+Alt+Fx to switch VTs, and SysRq combos). - The only way out is a hard power-off via holding the power button. On the next boot, the previous boot’s journal shows a kernel BUG in the i915 driver called from Xorg. System ====== - Debian GNU/Linux 13 (trixie) - Kernel versions installed: - 6.12.94+deb13-amd64 (linux-image-6.12.94+deb13-amd64 6.12.94-1) - 6.1.0-50-amd64 (linux-image-6.1.0-50-amd64 6.1.176-1) - Currently running when the bug occurs: uname -a ---------- - Linux muricanthus 6.12.94+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.94-1 (2026-06-20) x86_64 GNU/Linux - Hardware: lspci | grep -Ei 'vga|3d|display' --------------------------------- OUTPUT OF `lspci` HERE This is a System76 Serval WS laptop with both Intel iGPU and NVIDIA dGPU. The logs below show the X server (Xorg) using the Intel stack with the modesetting/i915 drivers. - Desktop: Xfce - Xfwm4 compositor: xfconf-query -c xfwm4 -p /general/use_compositing ------------------------------------------------- true Proprietary NVIDIA modules are also loaded (so the kernel is tainted P,O,E), but the crash trace is in i915 and drm_gem code. Crash trace =========== From the previous boot (journalctl -b -1), around the time of the freeze: journalctl -b -1 --since "2026-07-05 19:05" --until "2026-07-05 19:15" ---------------------------------------------------------------------- Jul 05 19:09:13 muricanthus kernel: perf: interrupt took too long (3138 > 3127), lowering kernel.perf_event_max_sample_rate to 63500 Jul 05 19:09:46 muricanthus kernel: BUG: unable to handle page fault for address: 0000000000800018 Jul 05 19:09:46 muricanthus kernel: #PF: supervisor write access in kernel mode Jul 05 19:09:46 muricanthus kernel: #PF: error_code(0x0002) - not-present page Jul 05 19:09:46 muricanthus kernel: PGD 0 P4D 0 Jul 05 19:09:46 muricanthus kernel: Oops: Oops: 0002 [#3] PREEMPT SMP NOPTI Jul 05 19:09:46 muricanthus kernel: CPU: 31 UID: 0 PID: 2027 Comm: Xorg Tainted: P D OE 6.12.94+deb13-amd64 #1 Debian 6.12.94-1 Jul 05 19:09:46 muricanthus kernel: Tainted: [P]=PROPRIETARY_MODULE, [D]=DIE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Jul 05 19:09:46 muricanthus kernel: Hardware name: System76 Serval WS/Serval WS, BIOS 2023-09-19_16ef69c 09/15/2023 Jul 05 19:09:46 muricanthus kernel: RIP: 0010:_raw_spin_lock_irqsave+0x27/0x50 Jul 05 19:09:46 muricanthus kernel: Code: 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 44 00 00 65 ff 05 98 a4 72 52 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 09 48 89 d8 5b c3 cc cc cc cc 89 c6 e8 a3 08 00 00 Jul 05 19:09:46 muricanthus kernel: RSP: 0018:ffffd22206b3bb20 EFLAGS: 00010046 Jul 05 19:09:46 muricanthus kernel: RAX: 0000000000000000 RBX: 0000000000000206 RCX: 0000000080400030 Jul 05 19:09:46 muricanthus kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000800018 Jul 05 19:09:46 muricanthus kernel: Call Trace: Jul 05 19:09:46 muricanthus kernel: <TASK> Jul 05 19:09:46 muricanthus kernel: i915_drm_client_remove_object+0x35/0xc0 [i915] Jul 05 19:09:46 muricanthus kernel: i915_gem_free_object+0x17/0x60 [i915] Jul 05 19:09:46 muricanthus kernel: drm_gem_object_release_handle+0x59/0xb0 [drm] Jul 05 19:09:46 muricanthus kernel: drm_gem_handle_delete+0x5d/0xa0 [drm] Jul 05 19:09:46 muricanthus kernel: drm_ioctl_kernel+0xad/0x100 [drm] Jul 05 19:09:46 muricanthus kernel: drm_ioctl+0x277/0x4d0 [drm] Jul 05 19:09:46 muricanthus kernel: __x64_sys_ioctl+0x94/0xc0 Jul 05 19:09:46 muricanthus kernel: do_syscall_64+0x87/0x1b0 Jul 05 19:09:46 muricanthus kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jul 05 19:09:46 muricanthus kernel: RIP: 0033:0x7fc1d8d3e91b ... Jul 05 19:09:46 muricanthus kernel: note: Xorg[2027] exited with irqs disabled Jul 05 19:09:46 muricanthus kernel: note: Xorg[2027] exited with preempt_count 1 After this, the system was effectively unresponsive (no VT switch, no SysRq keys), and I had to hold the power button to force a reboot. Repro / pattern =============== - Using Xfce with xfwm4 compositor enabled: xfconf-query -c xfwm4 -p /general/use_compositing ------------------------------------------------- true - Xorg is using the modesetting/i915 stack (see Xorg.0.log; can provide full log on request). - Running normal desktop workloads (web browser, PyTorch/transformers app using NVIDIA GPU). - After some time (tens of minutes to hours), the BUG above appears and the machine hard-freezes. I have also seen similar freezes on Debian 12 with xfwm4 compositor enabled, but there I did not capture the kernel BUG trace. Next steps / questions ====================== - Is this a known regression in the i915 driver in the 6.12.94 Debian kernel? - Are there any recommended workarounds besides disabling xfwm4 compositing or downgrading to the 6.1.0-50-amd64 kernel? - I can test: - Running with xfwm4 compositing disabled on 6.12.94. - Running with 6.1.0-50-amd64 on the same hardware. - Providing full dmesg, Xorg.0.log and additional traces as needed. Thank you for looking into this.
Control: tag -1 moreinfo [...] [...] There is no memory protection between kernel drivers, so any driver can cause another to crash. So please disable the nvidia driver temporarily and report whether this also occurs with only the i915 driver in use. Also, the kernel log you showed includes the 'D' flag indicating that there was an earlier crash. We really need to see the log for the first crash, which won't have the 'D' flag. Ben.
Hi Ben,
Following up on your request for a kernel log from a boot where the BUG
is the first crash (i.e. no `D` flag in the Tainted line):
Looking back through my journal history with:
journalctl --list-boots
for b in {-140..-1}; do
journalctl -b $b -k | awk '
/BUG: unable to handle page fault/ {bug=1}
bug && /Tainted:/ {print; exit}
'
done
I found the most recent boot log entry without the D flag is
boot -20 (2026-05-30) on kernel 6.1.0-44-amd64 (prior to the upgrade
from Debian 12 to Debian 13) where there is a BUG and the first
`Tainted:` line after it is:
May 30 16:55:47 muricanthus kernel: CPU: 6 PID: 1550 Comm: Xorg
Tainted: P OE 6.1.0-44-amd64 #1 Debian 6.1.164-1
The corresponding BUG is:
May 30 16:55:47 muricanthus kernel: BUG: unable to handle page fault
for address: ffff8ec141a42554 May 30 16:55:47 muricanthus kernel: #PF:
supervisor read access in kernel mode May 30 16:55:47 muricanthus
kernel: #PF: error_code(0x0000) - not-present page May 30 16:55:47
muricanthus kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI May 30 16:55:47
muricanthus kernel: CPU: 6 PID: 1550 Comm: Xorg Tainted: P OE
6.1.0-44-amd64 #1 Debian 6.1.164-1 May 30 16:55:47 muricanthus
kernel: Hardware name: System76 Serval WS/Serval WS, BIOS
2023-09-19_16ef69c 09/15/2023 May 30 16:55:47 muricanthus kernel: RIP:
0010:dma_resv_reserve_fences+0x21/0x210 [...]
I’ve attached the full kernel log for that boot as
`dmesg-first-crash-boot--20.log` (contents of `journalctl -b -20 -k`).
This is obviously not the same code path as the current i915
i915_drm_client_remove_object() BUG on 6.12.94+deb13-amd64, but it shows
that I have been seeing kernel BUGs related to Xorg/DRM prior to
upgrade, but there does not appear to be a record of non-D tainted
crash after the upgrade.
List from Boot -22 to the present is:
=== Boot -22 ===
=== Boot -21 ===
May 26 11:59:20 muricanthus kernel: CPU: 16 PID: 163372 Comm: Xorg
Tainted: P W OE 6.1.0-44-amd64 #1 Debian 6.1.164-1 ===
Boot -20 === May 30 16:55:47 muricanthus kernel: CPU: 6 PID: 1550 Comm:
Xorg Tainted: P OE 6.1.0-44-amd64 #1 Debian 6.1.164-1
=== Boot -19 === === Boot -18 ===
=== Boot -17 ===
=== Boot -16 ===
=== Boot -15 ===
=== Boot -14 ===
Jun 12 20:15:25 muricanthus kernel: CPU: 10 PID: 97048 Comm: Socket
Thread Tainted: P D OE 6.1.0-49-amd64 #1 Debian 6.1.174-1
=== Boot -13 === Jun 16 19:52:50 muricanthus kernel: CPU: 10 PID:
129361 Comm: IPDL Background Tainted: P B D W OE
6.1.0-49-amd64 #1 Debian 6.1.174-1 === Boot -12 === === Boot -11 ===
=== Boot -10 ===
=== Boot -9 ===
=== Boot -8 ===
=== Boot -7 ===
=== Boot -6 ===
=== Boot -5 ===
=== Boot -4 ===
[-4 is the First boot with 6.12.94+deb13-amd64: -4]
=== Boot -3 ===
=== Boot -2 ===
Jul 05 15:31:57 muricanthus kernel: CPU: 31 UID: 1001 PID: 7896 Comm:
Isolated Web Co Tainted: P D OE 6.12.94+deb13-amd64 #1
Debian 6.12.94-1 === Boot -1 ===
I’m still working on reproducing the 6.12.94+deb13-amd64 i915 BUG with
the NVIDIA driver disabled as you suggested, and when I catch that I’ll
send a `journalctl -b -1 -k` log from that boot as well.
I would indeed be suspicious of an NVIDA driver interaction, as this
sporadic behavior appeared to start after adding that to access CUDA
functionality on the GPU. If I recall correctly, I approached this
problem on Debian 12 by blacklisting the i915 driver.
Regards,
-Paul
On Mon, 06 Jul 2026 15:16:45 +0200 Ben Hutchings <ben@decadent.org.uk> wrote:
Hi Ben,
I’ve now reproduced a kernel BUG on 6.12.94+deb13-amd64 with the NVIDIA
driver fully disabled, and also have some additional information about
suspend/resume behaviour on this hardware.
1. Reproduced BUG with NVIDIA disabled
--------------------------------------
To disable NVIDIA I used:
/etc/modprobe.d/blacklist-nvidia-test.conf:
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_modeset
blacklist nvidia_uvm
install nvidia /bin/false
install nvidia_drm /bin/false
install nvidia_modeset /bin/false
install nvidia_uvm /bin/false
then ran `update-initramfs -u` and rebooted.
In this configuration:
lsmod | grep -i nvidia
----------------------
(no output)
so no NVIDIA modules are loaded, and Xorg.0.log shows only the Intel
modesetting/i915 stack in use.
Xfce’s compositor (xfwm4) was enabled:
$ xfconf-query -c xfwm4 -p /general/use_compositing
true
Under normal Xfce desktop load I again hit a hard lock similar to before
(mouse cursor not moving this time, keyboard completely dead, no VT
switch), requiring a power-button reset.
Immediately after reboot I ran:
sudo journalctl -b -1 -k > dmesg-crash-6.12.94-no-nvidia.log
In that log, the BUG appears as:
Jul 08 08:42:12 muricanthus kernel: BUG: unable to handle page fault
for address: ffffffff840f04fb Jul 08 08:42:12 muricanthus kernel: #PF:
supervisor write access in kernel mode Jul 08 08:42:12 muricanthus
kernel: #PF: error_code(0x0002) - not-present page Jul 08 08:42:12
muricanthus kernel: PGD 28a27067 P4D 28a27067 PUD 28a28063 PMD 0 Jul 08
08:42:12 muricanthus kernel: Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
Jul 08 08:42:12 muricanthus kernel: CPU: 9 UID: 0 PID: 2156 Comm: Xorg
Not tainted 6.12.94+deb13-amd64 #1 Debian 6.12.94-1 Jul 08 08:42:12
muricanthus kernel: Hardware name: System76 Serval WS/Serval WS, BIOS
2023-09-19_16ef69c 09/15/2023 Jul 08 08:42:12 muricanthus kernel: RIP:
0010:skl_compute_wm_params+0xb0/0x370 [i915] [...]
Note the `Not tainted` line, i.e. there is no `D` flag, so this is the
first crash in that boot.
I’ve attached the full kernel log as dmesg-crash-6.12.94-no-nvidia.log
(the contents of `journalctl -b -1 -k` in this configuration).
2. Suspend/resume: deep vs s2idle on i915 only
----------------------------------------------
Possibly relevant, or possibly unrelated, with NVIDIA disabled and
Xfce/i915 only, I also find that suspend/resume is failing to resume
(it was resuming with the i915 plus nvidia configuration).
Using the default `deep` (S3) suspend:
cat /sys/power/mem_sleep
------------------------
s2idle [deep]
systemctl suspend
results in:
- screens go blank, power LED turns off, the two external HDMI
monitors turn off;
- on attempted wake: black but powered up screens on all displays,
keyboard input is dead, unable to switch to a VTs
requiring a hard power-off.
From the corresponding boot’s kernel log I see:
Jul 08 07:36:32 muricanthus kernel: PM: suspend entry (deep)
and there is no matching `PM: suspend exit` or later resume messages
from that boot before the machine is powered off. I saved this as
dmesg-suspend-fail-i915-only.log (contents of `journalctl -b -1 -k`).
On the other hand, if I switch to s2idle:
echo s2idle > /sys/power/mem_sleep
and then suspend:
sudo systemctl suspend
I get a clean resume:
- VT3 login prompt and keyboard work after wake,
- Xfce session also resumes (via screensaver unlock prompt).
The current boot shows:
journalctl -b -k | grep -Ei 'PM: suspend entry|PM: suspend exit'
----------------------------------------------------------------
Jul 08 07:15:25 muricanthus kernel: PM: suspend entry (s2idle)
Jul 08 07:16:16 muricanthus kernel: PM: suspend exit
I have now set:
GRUB_CMDLINE_LINUX_DEFAULT="quiet mem_sleep_default=s2idle"
and `cat /sys/power/mem_sleep` reports:
[s2idle] deep
on subsequent boots. In this configuration, suspend/resume appears to
work reliably.
So on this hardware, with NVIDIA disabled:
- `mem_sleep=deep` suspend never reaches `PM: suspend exit` and leaves
the system wedged on resume;
- `mem_sleep=s2idle` works as expected.
Please let me know if you’d like me to attach the suspend-fail log
(dmesg-suspend-fail-i915-only.log) or provide any additional details
from Xorg logs, etc.
Regards,
-Paul
Hi Ben,
I’ve now reproduced a kernel BUG on 6.12.94+deb13-amd64 with the NVIDIA
driver fully disabled, and also have some additional information about
suspend/resume behaviour on this hardware.
1. Reproduced BUG with NVIDIA disabled
--------------------------------------
To disable NVIDIA I used:
/etc/modprobe.d/blacklist-nvidia-test.conf:
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_modeset
blacklist nvidia_uvm
install nvidia /bin/false
install nvidia_drm /bin/false
install nvidia_modeset /bin/false
install nvidia_uvm /bin/false
then ran `update-initramfs -u` and rebooted.
In this configuration:
lsmod | grep -i nvidia
----------------------
(no output)
so no NVIDIA modules are loaded, and Xorg.0.log shows only the Intel
modesetting/i915 stack in use.
Xfce’s compositor (xfwm4) was enabled:
$ xfconf-query -c xfwm4 -p /general/use_compositing
true
Under normal Xfce desktop load I again hit a hard lock similar to before
(mouse cursor not moving this time, keyboard completely dead, no VT
switch), requiring a power-button reset.
Immediately after reboot I ran:
sudo journalctl -b -1 -k > dmesg-crash-6.12.94-no-nvidia.log
In that log, the BUG appears as:
Jul 08 08:42:12 muricanthus kernel: BUG: unable to handle page fault
for address: ffffffff840f04fb Jul 08 08:42:12 muricanthus kernel: #PF:
supervisor write access in kernel mode Jul 08 08:42:12 muricanthus
kernel: #PF: error_code(0x0002) - not-present page Jul 08 08:42:12
muricanthus kernel: PGD 28a27067 P4D 28a27067 PUD 28a28063 PMD 0 Jul 08
08:42:12 muricanthus kernel: Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
Jul 08 08:42:12 muricanthus kernel: CPU: 9 UID: 0 PID: 2156 Comm: Xorg
Not tainted 6.12.94+deb13-amd64 #1 Debian 6.12.94-1 Jul 08 08:42:12
muricanthus kernel: Hardware name: System76 Serval WS/Serval WS, BIOS
2023-09-19_16ef69c 09/15/2023 Jul 08 08:42:12 muricanthus kernel: RIP:
0010:skl_compute_wm_params+0xb0/0x370 [i915] [...]
Note the `Not tainted` line, i.e. there is no `D` flag, so this is the
first crash in that boot.
I’ve attached the full kernel log as dmesg-crash-6.12.94-no-nvidia.log
(the contents of `journalctl -b -1 -k` in this configuration).
2. Suspend/resume: deep vs s2idle on i915 only
----------------------------------------------
Possibly relevant, or possibly unrelated, with NVIDIA disabled and
Xfce/i915 only, I also find that suspend/resume is failing to resume
(it was resuming with the i915 plus nvidia configuration).
Using the default `deep` (S3) suspend:
cat /sys/power/mem_sleep
------------------------
s2idle [deep]
systemctl suspend
results in:
- screens go blank, power LED turns off, the two external HDMI
monitors turn off;
- on attempted wake: black but powered up screens on all displays,
keyboard input is dead, unable to switch to a VTs
requiring a hard power-off.
From the corresponding boot’s kernel log I see:
Jul 08 07:36:32 muricanthus kernel: PM: suspend entry (deep)
and there is no matching `PM: suspend exit` or later resume messages
from that boot before the machine is powered off. I saved this as
dmesg-suspend-fail-i915-only.log (contents of `journalctl -b -1 -k`).
On the other hand, if I switch to s2idle:
echo s2idle > /sys/power/mem_sleep
and then suspend:
sudo systemctl suspend
I get a clean resume:
- VT3 login prompt and keyboard work after wake,
- Xfce session also resumes (via screensaver unlock prompt).
The current boot shows:
journalctl -b -k | grep -Ei 'PM: suspend entry|PM: suspend exit'
----------------------------------------------------------------
Jul 08 07:15:25 muricanthus kernel: PM: suspend entry (s2idle)
Jul 08 07:16:16 muricanthus kernel: PM: suspend exit
I have now set:
GRUB_CMDLINE_LINUX_DEFAULT="quiet mem_sleep_default=s2idle"
and `cat /sys/power/mem_sleep` reports:
[s2idle] deep
on subsequent boots. In this configuration, suspend/resume appears to
work reliably.
So on this hardware, with NVIDIA disabled:
- `mem_sleep=deep` suspend never reaches `PM: suspend exit` and leaves
the system wedged on resume;
- `mem_sleep=s2idle` works as expected.
Please let me know if you’d like me to attach the suspend-fail log
(dmesg-suspend-fail-i915-only.log) or provide any additional details
from Xorg logs, etc.
Regards,
-Paul