XPS 14 internal panel frozen after 3.7.0 upgrade — xe driver DSB timeout on Panther Lake

[rblalock]

System details

Omarchy 3.7, Dell XPS 2026

What's wrong?

Bug Report: XPS 14 (Dell DA14260) internal panel freezes on Omarchy 3.7 / kernel 7.0.3

Summary

After upgrading to Omarchy 3.7.0 (kernel 7.0.3-arch1-1-ptl), the laptop's internal panel (eDP-1) freezes completely during boot, before Hyprland starts. The external display (DP-1) works fine. Rolling back to the 3.6.0 snapshot (kernel 6.19.13-arch1-1-ptl) resolves the issue.

Hardware

• Laptop: Dell XPS 14 DA14260 (firmware 1.2.1)
• Panel: LG Display 0x07C6 (2880x1800)
• GPU: Intel Panther Lake (Core Ultra X7 358H) — xe driver, device ID 8086:b080
• External: LG TV via DP-1 (3840x2160) — works fine

Reproduction Steps

1. Be on Omarchy 3.7.0 with kernel 7.0.3-arch1-1-ptl
2. Boot with xe.enable_panel_replay=0 (already present from previous configs)
3. Internal eDP-1 panel freezes during DRM init, external DP-1 works normally

Expected Behavior

Internal panel should initialize and remain responsive, as it did on kernel 6.19.13.

Actual Behavior

Internal panel is completely frozen. Hyprland IPC times out when trying to re-enable it. Only external display is usable.

Kernel Errors (from journalctl -b 0 -k)

xe 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A
xe 0000:00:02.0: [drm] *ERROR* Tile0: GT1: GSC proxy component not bound!
xe 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] DSB 0 poll error
xe 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] flip_done timed out
xe 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] DSB 0 timed out waiting for idle (current head=0x240, head=0x0, tail=0x280)

Boot Parameters

Current (broken): fred=on rtc_cmos.use_acpi_alarm=1 resume=/dev/mapper/root resume_offset=3260137 xe.enable_panel_replay=0 quiet splash loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0 cryptdevice=PARTUUID=... root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs

Working Snapshot (for reference)

The 3.6.0 snapshot at 2026-05-04 11:48:36 (kernel 6.19.13-arch1-1-ptl) boots fine with identical boot parameters minus fred=on.

The 3.5.1 snapshot at 2026-04-23 (kernel 6.19.10-arch1-1-ptl) also worked and included xe.enable_psr=0.

What Was Tried (did not fix it)

• Forcing 60Hz and scale=2 on eDP-1 via ~/.config/hypr/monitors.conf — config applies but panel was already frozen from kernel init
• Cycling dpms off / dpms on via hyprctl — IPC timed out because the Xe DSB engine is deadlocked
• Rebooting with the 60Hz config — same freeze pattern, because the failure occurs during kernel DRM init before userspace

Root Cause Analysis

The regression appears to be in the Intel xe driver between kernel 6.19.13 and 7.0.3 on Panther Lake (device ID 8086:b080). The "Selective fetch area calculation failed in pipe A" error happens during boot-time DRM initialization, corrupting the display state buffer (DSB) for the internal panel. Once DSB is deadlocked, no userspace compositor can recover it.

Version Info

• Omarchy: 3.7.0
• Kernel: 7.0.3-arch1-1-ptl (broken) vs 6.19.13-arch1-1-ptl (working)
• Hyprland: 0.54.3
• Firmware: Dell 1.2.1 (2026-01-09)

[rblalock]

To confirm - i restored a snapshot, am on Omarchy 3.7 but Linux 6.19.13-arch1-1-ptl ... and this is working

[spencerbull]

Looking to drill down what the issue is. There should have been a migration that removed the xe.enable_panel_replay=0 (that disables panel replay) with the fix from 3.6.0 that enabled our panel power optimizations with panel replay.

Can you try removing that config and running a limine-update?

For reference, here are my params:
fred=on rtc_cmos.use_acpi_alarm=1 resume=/dev/mapper/root resume_offset=3251062 quiet splash loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0 cryptdevice=PARTUUID=<...>root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs

I'm still looking into why, with that flag enabled, it is throwing errors. The idea is that if you want disable panel replay, then it should still work without issues. I'll get back when I have more info, but might be worth a shot on your system to remove that flag and see what happens after a 3.7.0 upgrade.

[artjsalina5]

My /etc/default/limine after update:

...

ENABLE_UKI=yes
CUSTOM_UKI_NAME="omarchy"

ENABLE_LIMINE_FALLBACK=yes

# Find and add other bootloaders
FIND_BOOTLOADERS=yes

BOOT_ORDER="*, *fallback, Snapshots"

MAX_SNAPSHOT_ENTRIES=5

SNAPSHOT_FORMAT_CHOICE=5
KERNEL_CMDLINE[default]+=" xe.enable_panel_replay=0"
# Only show Panther Lake kernel in boot menu
BOOT_ORDER="linux-ptl*, *fallback, Snapshots"
KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3518698"
KERNEL_CMDLINE[default]+=" rtc_cmos.use_acpi_alarm=1"

I'll try removing and report back if I have the same issue.

[spencerbull]

@rblalock @artjsalina5

Okay to reproduce, if I have xe.enable_panel_replay=0 in my boot params I see the same behavior.

Good news is the short-term fix is easy, update your /etc/default/limine to remove xe.enable_panel_replay=0 and run a limine-update.

I will look into what is causing this in our patch files with the OLED for a longer-term fix.

CC: @dhh, I thought we had a migration that removed these. Could a migration be silently failing for some people when we removed those boot params?

[artjsalina5]

Concur that this works. fred=on was also not there with the migration, so I put that into /etc/default/limine

...
KERNEL_CMDLINE[default]+=" quiet splash"

ENABLE_UKI=yes
CUSTOM_UKI_NAME="omarchy"

ENABLE_LIMINE_FALLBACK=yes

# Find and add other bootloaders
FIND_BOOTLOADERS=yes

BOOT_ORDER="*, *fallback, Snapshots"

MAX_SNAPSHOT_ENTRIES=5

SNAPSHOT_FORMAT_CHOICE=5
KERNEL_CMDLINE[default]+=" fred=on "
# Only show Panther Lake kernel in boot menu
BOOT_ORDER="linux-ptl*, *fallback, Snapshots"
KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3518698"
KERNEL_CMDLINE[default]+=" rtc_cmos.use_acpi_alarm=1"

Was seeing some strange behavior with built in IPS panel, but a quick reset of ~/.config/hypr/monitors.conf to the default fixed it. Perhaps something to do with this.

[ryanrhughes]

@rblalock When you updated, were you sure to run omarchy-update? There's a migration specific to this in migrations/1776781956.sh that I'm curious if it never got ran or if the migration itself might have a hole in it we need to consider.

You can run this to verify if the migration ran as well:

[[ -f ~/.local/state/omarchy/migrations/1776781956.sh ]] && echo true || echo false

[ryanrhughes]

Found a pathway where this could have happened migrating from v3.5.0 and shipped a hotfix as https://github.com/basecamp/omarchy/releases/tag/v3.7.1.

[rblalock]

@rblalock When you updated, were you sure to run omarchy-update? There's a migration specific to this in migrations/1776781956.sh that I'm curious if it never got ran or if the migration itself might have a hole in it we need to consider.

You can run this to verify if the migration ran as well:

[[ -f ~/.local/state/omarchy/migrations/1776781956.sh ]] && echo true || echo false

Hey Ryan - yeh i ran the omarchy update way. That command above echo'd true fwiw.

I can confirm Spencer's comment works.