[BUG] Panther Lake Arc B370: VRR stutter and DSB poll errors on 7.2.2-1-cachyos

## Problem

Enabling VRR on my laptop's internal display causes visible stutter. With DSB enabled, the kernel repeatedly logs `DSB 0 poll error`. KWin logs `atomic commit failed: Device or resource busy`.

Disabling DSB at runtime stopped the DSB messages but did not improve the stutter. The same session later had screen corruption, plane faults and PSR warnings. I saved the log and rebooted. I do not know whether the later failure has the same cause as the original VRR problem.

## System

- Lenovo `21XM0005CD`; BIOS `R39ET28W (1.10)`, 2026-06-22
- Intel Core Ultra 5 338H; Arc B370, PCI `8086:b081`, subsystem `17aa:513d`; driver `xe`
- CachyOS, kernel `7.2.2-1-cachyos`, built 2026-08-28
- Plasma / KWin `6.7.4`, Wayland; Qt `6.11.2`; Mesa `26.2.2-arch3.2`
- One internal display: `eDP-1`, `2880x1800` at `120 Hz`, 200% scale
- KWin uses OpenGL/EGL and DRM atomic modesetting.

The panel make and model have not been collected. All logs here are from `7.2.2-1-cachyos`. I have not tested Arch Linux's `linux` kernel, mainline or `drm-tip`, and I have not verified this on a newer CachyOS kernel. I stopped the runtime test after the display became corrupted and am reporting the saved evidence first.

## Original failure, before changing DSB

With the panel set to 120 Hz, changing KDE Adaptive Sync from **Never** to **Always** causes visible stutter. `kscreen-doctor` confirmed `Vrr: Always`. DSB read back as `Y` before the runtime test.

```text
xe 0000:00:02.0: [drm] *ERROR* [CRTC:151:pipe A] DSB 0 poll error
```

KWin's original error is:

```text
atomic commit failed: 设备或资源忙
```

The Chinese text means "Device or resource busy". These errors were present before DSB was disabled.

Expected: VRR should not cause persistent stutter or repeated display errors. I have no measured FPS comparison, recorded test application or known-good kernel version.

## Separate runtime DSB test

1. Set VRR to Never.
2. Changed `/sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_dsb` from `Y` to `N`; readback was `N`.
3. Set VRR to Always and checked the policy.
4. DSB errors stopped, but the stutter did not improve at all.
5. Later in the same session, the display became corrupted and I had to reboot.

On September 5, the log shows plane 1A faults at 18:22, followed by these errors at 18:25:

```text
CPU pipe A FIFO underrun
Timed out waiting PSR idle state
drm_WARN_ON(intel_dp->psr.active)
WARNING: drivers/gpu/drm/i915/display/intel_psr.c:2050 at intel_psr_activate+0x391/0xd10 [xe]
```

The trace includes `intel_psr_resume`, `intel_cx0pll_readout_hw_state`, `mtl_ddi_cx0_get_config`, `intel_modeset_verify_crtc` and `intel_atomic_commit_tail`.

The DSB write is not timestamped in the kernel log. This test does not establish whether disabling DSB caused the later corruption. PSR and Panel Replay were not disabled during this test.

## PSR snapshot and reboot

A status read during the investigation showed:

```text
PSR mode: Panel Replay Selective Update enabled (Early Transport)
Source PSR/PanelReplay ctl: disabled [0x00000000]
Source PSR/PanelReplay status: IDLE [0x04002400]
```

This was one snapshot, not proof that Panel Replay stayed active throughout the failure.

After reboot, DSB reads `Y`. The new boot log has no DSB poll errors, plane faults, FIFO underrun or PSR idle timeout in the captured period. It has `Selective fetch area calculation failed in pipe A` before `Initialized xe`.

DMC `i915/xe3lpd_dmc.bin` v2.36 loaded. The log records GuC `70.72.1`, HuC `10.3.3` and GSC `105.0.2.1397`.

## Log scope

The fault log starts at 18:04 and includes the full warning trace, but not that boot's initialization. The reboot log is from a separate boot. The KWin excerpt covers the original failure. The PSR snapshot's exact capture time was not recorded.

## Possibly related

- https://github.com/hyprwm/Hyprland/discussions/14729 — VRR stutter on another Panther Lake internal panel, under Hyprland.
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163125 — a separate display corruption report.
- #1014 — the same kernel and KWin versions, but an Alt+Tab failure on a different GPU with no kernel errors.

I cannot confirm a shared cause. Does this need a CachyOS patch check before a separate `xe` report?

## Attachments

[ptl-vrr-logs.zip](https://github.com/user-attachments/files/31863336/ptl-vrr-logs.zip)

The ZIP contains the fault-session log with the full warning trace, a separate boot log, the KWin error excerpt, the PSR status snapshot and system information. Private identifiers have been redacted from the boot log and KWin excerpt.

Start with the attached fault-session log and the trace entries in drivers/gpu/drm/i915/display/intel_psr.c, then compare the separate reboot log and KWin excerpt. Reproduce VRR Always on eDP-1 at 120 Hz with DSB enabled, recording timestamps and whether the DSB, PSR, plane, and FIFO errors recur; compare with DSB disabled. Done means identifying whether this is a reproducible xe/kernel defect and providing a focused upstream or CachyOS patch check.

Written by the indexing model from the issue text.