Adding a data point from different but closely related hardware, in case it helps narrow down whether this is Arrow-Lake-S-specific or a broader Meteor/Arrow Lake PHY power-management issue.
System: Lenovo ThinkPad P1 Gen 8, Intel Arrow Lake-P iGPU (Arc Pro 130T/140T, PCI ID 8086:7d51, identifies as "meteorlake D0" in dmesg like the reporter's system), NVIDIA RTX PRO 2000 Blackwell (hybrid graphics, prime-select=nvidia). Ubuntu 26.04, tested on both 7.0.0-27-generic and linux-oem-26.04a (7.0.0-1008-oem / 7.0.0-1009-oem). Note: this is a hybrid-graphics (Optimus-style) setup with prime- select=nvidia — all rendering/compute runs on the NVIDIA GPU, the Intel iGPU is otherwise idle. However, the internal panel (eDP-1) is hard- wired to the iGPU (no MUX/vgaswitcheroo available) and must still be driven by i915 for display output, which is where the PHY A/DDI BUF A errors occur. So this doesn't appear to be related to iGPU render/compute load — it's purely the display-scanout/PHY power-state path. Identical error signature on every occurrence: i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle. i915 0000:00:02.0: [drm] *ERROR* PHY A Read 0c70 failed after 3 retries. i915 0000:00:02.0: [drm] *ERROR* PHY A Write 0c70 failed after 3 retries. i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle patterns followed by a hard freeze (fsck dirty-bit / corrupted journal on next boot, no clean shutdown sequence). Trigger pattern differs slightly from the reporter's: in my case most occurrences have no PM: suspend entry in the journal at all — i.e. plain runtime idle/display-powerdown while the session is logged in and idle (no lid close, no explicit suspend), both docked and undocked, both on AC and battery. One occurrence did involve an aborted s2idle resume (an "early wake event" that cancelled the suspend almost immediately), which produced the exact same signature. This suggests the underlying PHY power-down/restore path in intel_cx0_phy.c may be reachable both via suspend/resume and via normal DC-state idle transitions, not only via long s2idle dwell — might be worth checking whether the fix needs to cover both paths. Workarounds tried, none effective: i915.enable_psr=0, i915.enable_dc=0 (alone and combined), PCI runtime-PM keep-on (echo on > /sys/bus/pci/devices/0000:00:02.0/power/control), and switching to the xe driver (i915.force_probe=!7d51 xe.force_probe=7d51) — the xe path also froze in 2 of 4 tested boots with the same underlying pattern (journal corruption, no clean shutdown), so it doesn't appear to be i915-specific either. Note on vendor support: Lenovo support's only response when I reported this was to point to the official certification page (ubuntu.com/certified) for this exact model, which lists only Ubuntu 24.04 LTS with kernel 6.14.0-1015-oem as certified/tested, explicitly warning that "standard images of Ubuntu may not work well, or at all." I haven't been able to reproduce (or rule out) the bug on that specific certified combination yet, but if it turns out to be clean there, that would narrow the regression window down to somewhere between 6.14-oem and 7.0/7.1 generic/oem — might be a useful data point for bisecting. Happy to provide full journal excerpts or test a proposed patchoduces reliably (roughly every few hours of idle) on my system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2150605 Title: `i915 Arrow Lake-S: PHY A / C10 DPLL state mismatch on resume from long s2idle dwell — slow wake (5-10s) with retry storm` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150605/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
