Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: During normal desktop interaction in KDE Plasma 6.6.4 Wayland (KWin), the system experiences brief whole-display freezes (10–30 seconds) where the compositor cannot paint. Mouse and keyboard input are not reflected on screen during the freeze. The freezes coincide with i915 driver errors logged to the kernel about PSR2 selective fetch and atomic update (vblank) failures. The symptom matches the existing Fedora discussion at https://discussion.fedoraproject.org/t/testing-request-graphical-corruption-on-intel-laptops-on-kernel-6-19/182061 which reports the same class of failures on Meteor Lake / Arrow Lake-H. This report adds Arrow Lake-U (Core Ultra 200 U-series) to the affected hardware list. The Fedora discussion thread states the underlying bug is already fixed upstream; the value of filing this is to (a) confirm Arrow Lake-U is on the affected list, and (b) push the upstream fix into a Fedora 44 kernel rebase. 2. What is the Version-Release number of the kernel: kernel-6.19.14-300.fc44.x86_64 Other relevant package versions: linux-firmware-20260410-1.fc44.noarch mesa-dri-drivers-26.0.5-3.fc44.x86_64 kwin-6.6.4-2.fc44.x86_64 xorg-x11-server-Xwayland-24.1.11-1.fc44.x86_64 i915 firmware: DMC: i915/mtl_dmc.bin v2.23 GuC: i915/mtl_guc_70.bin v70.53.0 HuC: i915/mtl_huc_gsc.bin v8.5.4 GSC: i915/mtl_gsc_1.bin (cv1.0, r102.1.15.1926, svn 1) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Symptom first noticed during the week of 2026-05-04 on kernel 6.19.14-300.fc44 (installed 2026-04-30, replacing 6.19.14-200.fc43). I do not have firm evidence about behaviour on the older kernel. Happy to test a pinned older kernel if requested. 4. Can you reproduce this issue? Intermittent but recurring. Multiple events per day on each of 2026-05-05 and 2026-05-06. Reproduction trigger heuristic: heavy compositor load — Alt+Tab through many open windows, mouse-drag of a window with active content underneath, switching virtual desktops with many running apps. Steps: 1. Boot KDE Plasma 6.6.4 Wayland on the affected hardware. 2. Open a normal desktop workload — multiple Vivaldi/Chromium windows, Microsoft Teams, terminal, file manager. 3. Use Alt+Tab repeatedly to cycle through windows, or perform any action that requires a full-screen compositor refresh. 4. The display occasionally freezes for 10–30 seconds. After recovery the kernel log contains an i915 PSR2 / atomic-update error. Actual: compositor stalls; whole UI is unresponsive. Kernel log shows one or both of: i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=44714 end=44715) time 428 us, min 1193, max 1200, scanline start 1177, end 1209 Expected: no display stall; PSR2 selective fetch should fall back to a full update when the area is degenerate, rather than missing the vblank deadline. Concurrent kwin warning during these stalls: kwin_wayland Libinput: ... lagging behind by 51ms, your system is too slow ==== Additional information ==== Hardware System: Lenovo ThinkPad 21NXCTO1WW BIOS: N4MET28W (1.15) 02/25/2026 CPU: Intel Core Ultra 7 265U (Arrow Lake-U) iGPU: Intel Arrow Lake-U Graphics PCI 0000:00:02.0 — 8086:7d41 Subsystem 17aa:2340 (Lenovo) Driver: i915 (kernel modules also include xe but i915 is bound) Userspace: Fedora 44, KDE Plasma 6.6.4 Wayland (KWin) Workarounds `i915.enable_psr=0` on the kernel command line is reported in the Fedora discussion thread to suppress the symptom. Not yet applied at the time of this report. Cross-references - Fedora discussion (active thread for this regression): https://discussion.fedoraproject.org/t/testing-request-graphical-corruption-on-intel-laptops-on-kernel-6-19/182061 - Fedora discussion — same kernel, similar symptom on ThinkPad P16s Gen 3: https://discussion.fedoraproject.org/t/f44-freezes/190466 - Existing related Bugzilla on older hardware (closed): https://bugzilla.redhat.com/show_bug.cgi?id=1375399 Logs attached separately i915-psr-log-excerpt.txt — i915 errors observed across last three boots system-info.txt — DMI, kernel, package versions, lspci Reproducible: Always
Created attachment 2140024 [details] i915 PSR errors across last three boots
Created attachment 2140025 [details] DMI / kernel / package versions / lspci
Update: still reproduces on kernel 7.0.x (Fedora 44). I upgraded from 6.19.14-300.fc44 through the 7.0 series and the PSR2 errors persist. The Fedora 6.19 graphical-corruption discussion thread indicated the underlying fix had landed upstream, but on this Arrow Lake-U hardware the symptom is still present on 7.0. Currently running: kernel-7.0.10-201.fc44.x86_64 (also seen on 7.0.4 and 7.0.9) linux-firmware-20260519-1.fc44.noarch mesa-dri-drivers-26.0.7-2.fc44.x86_64 kwin 6.6.4, KDE Plasma 6.6.4 Wayland The errors continue to appear in clusters during normal desktop use (window switching / compositor activity). Representative entries from the current boot on 7.0.10: Jun 01 08:48:44 kernel: i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A Jun 01 11:13:09 kernel: i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=427088 end=427089) time 338 us, min 1193, max 1200, scanline start 1183, end 1185 Jun 01 13:15:48 kernel: i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=843627 end=843628) time 348 us, min 1193, max 1200, scanline start 1175, end 1177 Equivalent errors were also logged on the 7.0.4 and 7.0.9 kernels on 2026-05-18, 05-19 and 05-20 (multiple per day), so this is not specific to a single 7.0.x build. User-visible effect: brief whole-compositor stalls; kwin occasionally logs "The main thread was hanging temporarily!" in the same window. Hardware (unchanged from the initial report): Lenovo ThinkPad 21NXCTO1WW, BIOS N4MET28W (1.15) 02/25/2026 Intel Core Ultra 7 265U (Arrow Lake-U) iGPU 8086:7d41, subsystem 17aa:2340 Driver i915 (kernel also ships xe; i915 is bound) Internal eDP-1 1920x1200@60 + external HDMI-A-1 1920x1080@60, both pipes active when the errors occur.
Possibly related report on a different Arrow Lake SKU, filed separately since the exact trigger and log signature differ from this bug, but it looks like the same underlying PSR2/pipe-A fragility on this display-engine generation. - Platform: Intel Arrow Lake-P (Arc Pro 130T/140T, 8086:7d51) on a Lenovo ThinkPad (T1g Gen 8 family) — same vendor/family as this report's 21NXCTO1WW, different iGPU SKU (Arrow Lake-P vs -U here). Internal panel is a Samsung `ATNA60KA02-0` OLED panel (3200x2000, HBR3/4-lane link at failure) rather than the more common FHD IPS — possibly relevant to reproducibility given the near-maximum link bandwidth involved, flagged as a hypothesis rather than a confirmed factor. - Kernel 7.0.0-30-generic, Ubuntu 26.04 LTS, i915 (not xe), GNOME Shell 50.1 / Wayland — distro noted for completeness, but this is an upstream driver bug, not distro-specific. - Signature: `Timeout waiting for DDI BUF A to get active`, `Timed out waiting for DP idle patterns`, `[CRTC:150:pipe A] flip_done timed out`, pixel_rate/dpll_hw_state/port_clock mismatches, `pipe state doesn't match!` — rather than this bug's "Selective fetch area calculation failed"/"Atomic update failure on pipe A". - Trigger: mainly on session unlock after idle. Also, prior to disabling PSR, on a separate path via Chromium (running as a snap) attempting to inhibit screen-blank during video playback and being blocked by AppArmor confinement — an unrelated pre-existing issue that happened to expose the same underlying PHY-retrain defect. - Frequency, measured against 13 days of journal history: 18 occurrences against 69 session unlocks. - **Three obvious kernel-level workarounds were tried; none fix this:** `i915.enable_psr=0` alone reduced the trigger paths (closed off the Chromium/video-adjacent one) but the bug recurred via the unlock path within about 10 hours. Adding `i915.enable_dc=0` on top (disabling all DC-state display power-gating, not just PSR) did not help either — it recurred again on the next overnight lock/unlock cycle, that time escalating to a full freeze. Adding `i915.enable_dmc_wl=1` on top of both (DMC wakelock — guards the driver against touching display/PHY registers while the DMC firmware coprocessor is mid-transition) *also* did not help — it recurred again the same day. All three parameters are effectively ruled out as fixes on this platform, individually or stacked together. - **Debug-verbosity captures (`drm.debug=0x15e`) show a deterministic, not race-driven, failure:** two self-heal incidents ~5.5 hours apart (the second with `enable_dmc_wl=1` additionally active) produced *bit-for-bit identical* PHY/PLL register state — same `c10pll_hw_state` mismatch values, same raw PHY dump, same `intel_cx0_wait_for_ack` status code (`0xa0008000`), same retry sequence and ~45s duration. Since `enable_dmc_wl` specifically guards against timing-dependent races, getting identical state twice (once with the guard active) argues this is a fixed defect in the CX0 PHY control/link-training sequence rather than a race — which is consistent with why none of the three power-management workarounds tried so far have helped. - **Three distinct outcomes follow the same initial error signature:** (1) self-heals within ~1 minute via automatic kernel retries — observed 5 times, including 3 since the workarounds above were applied, unaffected by any of them; (2) long-running retry loop that never succeeds but leaves the rest of the system usable (observed via a still-working external monitor on a separate pipe); (3) a full, silent system freeze — all kernel-level logging stops across every subsystem, no panic, no watchdog hit, no crash dump captured despite kdump being armed — requiring a hard power-cycle. The freeze outcome has now been confirmed under both default `enable_dc=-1` and `enable_dc=0`, so it predates and is independent of that workaround attempt. Filed the DDI-BUF/idle-pattern variant separately at: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16958 Flagging here in case it's useful for triage — both reports point at PSR2/ display-engine power-management stability on this generation rather than either being a narrow, isolated bug, and the silent-freeze outcome in particular seems worth escalating given the lack of any diagnostic trace (no panic, no vmcore) to work from when it happens. (Note: this comment was compiled with AI assistance (Claude) analyzing live system logs on the affected machine, under my direction and review; all log excerpts and commands cited are independently reproducible via `journalctl` on the system.)