Public bug reported:
# [regression] i915: list corruption in `__i915_active_fence_set` on
first execbuffer after S3 resume -> NULL deref -> endless rcs0 GPU hangs
-> internal panel stays black (Ivybridge, 7.0.0-38-generic; 6.8.x is
clean)
**Affects:** linux (Ubuntu) / Ubuntu 26.04.1 LTS "resolute"
**Tested kernels:** 7.0.0-38-generic (FAIL), 6.8.0-139-generic (OK),
6.8.0-117-lowlatency (OK), 6.8.0-146-lowlatency (OK)
**Attachment:** `i915-resume-oops-attachment.txt`
---
## Summary
After upgrading to `linux-image-7.0.0-38-generic`, resuming from **deep (S3)**
suspend leaves the internal laptop panel permanently black. The system itself
resumes fine: `PM: suspend exit` is logged, tasks restart, Wi-Fi reconnects,
Bluetooth comes up and GDM accepts input. Only the display never comes back,
so the machine has to be power-cycled.
This is **not** a display/backlight problem. The kernel logs an i915 list
corruption and a NULL-pointer oops on the first GPU submission after resume,
then enters an endless GPU-reset loop:
```
list_add corruption. prev->next should be next (ffff8b5c9e3aec10), but was
0000000000000000. (prev=ffff8b5d847ece20).
WARNING: lib/list_debug.c:32 at __list_add_valid_or_report+0x87/0xc0, CPU#1:
gnome-sh:gdrv0/1664
...
__i915_active_fence_set.cold+0xc/0x2a [i915]
i915_active_add_request+0x8f/0x260 [i915]
_i915_vma_move_to_active+0xdb/0x380 [i915]
eb_move_to_gpu+0xd3/0x3c0 [i915]
i915_gem_do_execbuffer+0xe73/0x13a0 [i915]
i915_gem_execbuffer2_ioctl+0x137/0x260 [i915]
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] SMP PTI
RIP: 0010:__i915_active_fence_set+0x2a8/0x2e0 [i915]
Code: ... 49 8b 47 10 49 8b 57 08 49 8d 5f 08 <48> 3b 18 ... (cmp (%rax),%rbx
with RAX=0)
CR2: 0000000000000000
i915 0000:00:02.0: [drm] GPU HANG: ecode 7:0:00000000
i915 0000:00:02.0: [drm] GPU error state saved to /sys/class/drm/card1/error
i915 0000:00:02.0: [drm] Resetting rcs0 for no heartbeat on rcs0
... repeats every ~6s until power cycle
```
The chain is `i915_gem_do_execbuffer()` -> `eb_move_to_gpu()` ->
`_i915_vma_move_to_active()` -> `i915_active_add_request()` ->
`__i915_active_fence_set()`. The list node handed to `__list_add_valid()` has a
NULL `next` pointer, i.e. the VMA's active-fence list is already corrupt before
the new fence is spliced in. The compositor (gnome-shell thread `gdrv0`) can
never present a frame again, which is why the panel stays black.
This looks like a lifetime bug in the i915 active-fence tracking (a fence /
`i915_request` being unlinked, freed and reused while still linked), exposed
only on the resume path. Flagging as a hypothesis, not a diagnosis - no bisect
has been done.
## Environment
| | |
|---|---|
| Machine | Lenovo ThinkPad X230 Tablet, model 34382AG |
| BIOS | GCETB5WW (2.75), 09/25/2019 (latest available) |
| GPU | Intel 3rd Gen Core processor Graphics Controller `[8086:0166]` rev 09
(Ivybridge GT2), display version 7 |
| Driver | in-tree `i915.ko`, `vermagic 7.0.0-38-generic`, `srcversion
AD9B846A7B0941179320D5F` (not DKMS/out-of-tree) |
| Display | internal LVDS-1 only; no external monitor attached |
| OS | Ubuntu 26.04.1 LTS (resolute), GNOME Shell 50.1 on Wayland |
| Userspace | Mesa 26.0.8, libdrm 2.4.131 (unchanged across the working/failing
kernels) |
| Suspend | `PM: suspend entry (deep)` - S3, `/sys/power/mem_sleep` = `s2idle
[deep]` |
| Kernel cmdline | `ro quiet splash preempt=full rcu_nocbs=all` (both kernels,
see "Not yet ruled out") |
## Regression / impact
Everything before the kernel change is clean; the very first resume on
7.0.0-38-generic fails. Resumes are logged as `PM: suspend exit`; "i915 errors"
counts the lines matching `list_add corruption|list_del
corruption|__i915_active_fence_set|GPU HANG`:
| kernel | resumes | i915 errors |
|---|---|---|
| 6.8.0-117-lowlatency | 54 | 0 |
| 6.8.0-139-generic | 54 | 0 |
| 6.8.0-146-lowlatency| 0 | 0 |
| **7.0.0-38-generic**| **1** | **50** |
The failing boot ran 2026-10-08 22:27 -> 2026-10-09 16:16 and did not survive
its first resume. A follow-up boot failed again on its first resume. The
regression appeared the day `linux-generic` moved 6.8.0-146 -> 7.0.0-38
(2026-10-08 21:57 install, 22:21 configure).
Counts reproducible with:
```
journalctl --list-boots
journalctl -b <ID> -k | grep -c "PM: suspend exit"
journalctl -b <ID> | grep -cE "list_add corruption|list_del
corruption|__i915_active_fence_set|GPU HANG"
```
## Steps to reproduce
1. Boot `7.0.0-38-generic` on this machine (GNOME/Wayland session, no external
display).
2. Suspend: close the lid, or `sudo systemctl suspend`.
3. Wake via power button / lid open.
4. Panel stays black; the machine is otherwise alive (SSH/Wi-Fi respond).
5. `journalctl -b -1 -k` shows the list corruption, the NULL deref and the rcs0
reset loop.
Reproduced 2 out of 2 attempts on 7.0.0-38-generic. Not reproducible on
6.8.0-139-generic or 6.8.0-117-lowlatency over 108 resumes.
## What I ruled out
- **Not userspace / Mesa / GNOME Shell.** The crash is a kernel oops in i915;
the
`drm_ioctl` caller is just the victim. Mesa and GNOME Shell versions are
identical
on the working and failing kernels.
- **Not the DPCD/backlight class of bug.** The panel is dark because the GPU
can no
longer present, not because of brightness.
`/sys/class/backlight/intel_backlight`
reads back normally while the screen is dark, and
`i915.enable_dpcd_backlight` is
irrelevant here (`type=raw`, PWM path on this platform).
- **Not PSR / display C-states.** This is Gen7: the 6.8 kernel's own
display-info
dump reports `has_psr: no`, `has_dmc: no`, `has_ddi: no`, so
`i915.enable_psr=0`
and `i915.enable_dc=0` do not apply.
- **Not missing i915 firmware.** Ivybridge needs no GuC/HuC/DMC blobs.
- **Not the suspend mode.** The machine is using `deep` (S3), which is the
correct
mode for it, and the same mode works on 6.8.x.
- **Not a local misconfiguration.** No i915 module parameters, no files in
`/etc/modprobe.d/` affecting i915, no `systemd-sleep` hooks besides the stock
ones. `/etc/systemd/system-sleep/` contains only `hdparm`, `iwlwifi-reset`,
`sysstat.sleep`, `unattended-upgrades`.
## Not yet ruled out (checked, but not proven)
The kernel command line also changed on the same day as the kernel: it went from
`quiet splash vt.handoff=7` to `quiet splash preempt=full rcu_nocbs=all`.
Reason: `grub-mkconfig` only started sourcing `/etc/default/grub.d/*.cfg` after
the GRUB upgrade that came with the same release upgrade, which activated a
pre-existing `lowlatency-kernel` snippet setting those two parameters.
Suggestive but not conclusive evidence that this is not the trigger: the kernel
I am currently running, `6.8.0-146-lowlatency`, boots with **the same**
`preempt=full rcu_nocbs=all` command line and has since resumed cleanly. I have
not tested 7.0.0-38-generic without those parameters.
## Workaround in use
Pinning `GRUB_DEFAULT` / `saved_entry` to the `6.8.0-146-lowlatency` entry and
marking `linux-image-lowlatency` as manually installed, so the machine stays
usable. `7.0.0-38-generic` remains installed and selectable. This is a
workaround, not a fix: it means running without 7.0 kernel updates.
## Possibly related existing reports
Different signatures, but same platform class and the same "7.0 i915 breaks
resume, 6.8/6.17 is fine" shape - worth cross-referencing:
- LP #2163734 - i915/Haswell: black screen after resume from S3 on 7.0 kernels,
`assert_can_disable_lcpll` WARNING (regression vs 6.17). Call path is
`hsw_disable_lcpll` / `intel_display_power_suspend_late`, i.e. suspend-late
power, not execbuffer - different from this trace.
- LP #2161881 - i915: "Failed to open drm device" / atomic modeset EINVAL after
resume (Kaby Lake-R, 7.0 series).
- LP #2161575 - i915 resume black screen fixed by `i915.enable_dpcd_backlight=0`
(backlight path).
None of them contains `__i915_active_fence_set` or a `list_add corruption`, so I
believe this is a separate defect.
## Request
- A bisect between `6.8.0-139-generic` (good, 54 clean resumes) and
`7.0.0-38-generic` (bad, fails on the first resume), or a pointer to the
active-fence / request-lifetime change in the 7.0 series that could produce a
NULL `next` in a VMA's active list on the first post-resume execbuffer.
- Happy to test patches, run `drm.debug`/`i915.debug` traces, capture
`/sys/class/drm/card1/error`, or run any igt test on request. The machine is
available and the failure is 100% reproducible on 7.0.0-38-generic (which I
keep installed for exactly this purpose).
---
Raw logs, per-boot statistics and full call traces:
`i915-resume-oops-attachment.txt`.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170367
Title:
internal panel stays black after LTS release upgrade
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170367/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
