Bug 2467676
| Summary: | i915: "Atomic update failure on pipe A" / PSR2 selective fetch failure causes compositor freezes on Arrow Lake-U (Core Ultra 7 265U) with kernel 6.19.14-300.fc44 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | redhat | ||||||
| Component: | kernel | Assignee: | Justin M. Forbes <jforbes> | ||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 44 | CC: | acaringi, adscvr, airlied, hans, heinze.martin, hpa, jforbes, kernel-maint, linville, masami256, mchehab, nickolasjcarr, ptalbert, redhat, steved, suraj.ghimire7 | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | --- | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | Type: | --- | |||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
redhat
2026-05-07 10:40:02 UTC
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.) |