Crash and restart after omarchy-system-lock

[filip-spaldon]

System details

Omarchy 3.8.3

What's wrong?

System details

• PC: Framework Desktop (AMD Ryzen AI Max 300 Series)
• CPU/APU: AMD Ryzen AI Max 385 w/ Radeon 8050S (Strix Halo, gfx11)
• GPU: amdgpu 0000:c2:00.0, VRAM 16384M (UMA), ATOM BIOS 113-STRXLGEN-001
• SMU firmware: 0x0a640600 (100.6.0)
• Omarchy: 3.8.3
• Kernel: 7.1.3-arch1-2 (broken) — 7.0.10-arch1-1 confirmed working (rollback tested)
• linux-firmware-amdgpu: 20260622-1 (broken) — 20260519-1 confirmed working
• mesa: 1:26.1.4-1 (broken) — 1:26.1.1-2 confirmed working
• Hyprland: 0.55.4-1

What's wrong

Since upgrading to Omarchy 3.8.3 (bumps linux 7.0.10→7.1.3, linux-firmware-amdgpu 20260519→20260622, mesa 26.1.1→26.1.4, hyprland 0.55.2→0.55.4), the system immediately hard-freezes and force-reboots as soon as the display is turned off via DPMS — whether triggered by omarchy-system-lock, a custom hyprctl dispatch dpms off keybind, or automatically via hypridle's idle timeout. No delay — the reboot happens right at the point the screen goes dark.

There is no clean shutdown in the journal (no unmounting sequence, no kernel panic, no amdgpu reset/timeout messages) — the journal just stops, consistent with a hard hang forcing an external/hardware reset.

Reproduction steps

hyprlock &
sleep 3
hyprctl dispatch dpms off

→ Display turns off → system force-reboots immediately. Reproduced consistently (4/4 attempts) via both manual and hypridle-automatic triggering.

Key log evidence

Journal simply ends mid-stream, no error, no shutdown sequence:

Jul 14 21:08:40 omarchy kernel: [UFW BLOCK] IN=enp191s0 ... (normal traffic)
Jul 14 21:08:42 omarchy kernel: [UFW BLOCK] IN=enp191s0 ...
--- journal ends, next boot starts ~1 min later, no panic/reset/coredump anywhere ---

Key findings

• Rolling back kernel + linux-firmware-amdgpu + mesa to pre-3.8.3 versions (via btrfs/limine snapshot) completely fixes it — same hardware, same repro steps, zero crashes. Strongly points to a regression in one of these three packages between the given versions.
• Locking without triggering DPMS off (OMARCHY_LOCK_ONLY=true omarchy-system-lock) does not crash by itself — confirms DPMS off specifically is the trigger, not hyprlock rendering.
• No amdgpu/SMU/VPE error is ever logged before the crash

Happy to provide more logs if useful.

[dhh]

Hmm. I haven't been able to replicate this on my 385 Framework Desktop. Wonder where it differs. You might want to try to pin it down further by downgrading either mesa or linux-firmware-amdgpu packages. Then if we have a clear fix on where it's going wrong, it'll be easier to get it sorted upstream.

[filip-spaldon]

Bisect results — the culprit is linux 7.1.3

I've narrowed it down by downgrading each package individually and testing the repro after each step. Here's what I found:

Package	Downgraded to	Result
mesa	1:26.1.1-2 (keeping kernel 7.1.3 + firmware 20260622)	Still crashes
linux-firmware-amdgpu	20260519-1 (keeping kernel 7.1.3 + mesa 26.1.4)	Still crashes
linux	7.0.10-arch1-1 (keeping mesa 26.1.4 + firmware 20260622)	Fixed — no crash

So the regression is specifically in linux 7.1.3-arch1-2 (or 7.1.x in general). Neither mesa 26.1.1→26.1.4 nor linux-firmware-amdgpu 20260519→20260622 are contributing factors.

Happy to help with further testing... Thank you

[SmartALB]

Running the exact same software stack you flagged, but DPMS-off does not freeze here:

• APU: AMD Ryzen AI Max+ 395 w/ Radeon 8060S (Strix Halo) — note: 395, not the 385/8050S in the report
• Form factor: Desktop (board "AMD Ryzen AI Max 300 Series"), BIOS 03.05 (2026-01-21)
• Kernel: 7.1.3-arch1-2 · mesa: 1:26.1.4-1 · linux-firmware-amdgpu: 20260622 · Omarchy: 3.8.3 (all matching the affected versions)
• amd_pstate: active
  hyprctl dispatch dpms off fired for real today via the 15-min idle auto-lock (Omarchy's lock path calls dpms off after a 3s delay) and via the standalone hypridle DPMS listener. No hard freeze, no reboot — uptime has been continuous. Display powered off and woke normally.
  So on this hardware the regression does not trigger, which suggests the crash may be specific to the 385/8050S variant (or a mobile/mini form factor, BIOS, or panel/VRR setup) rather than to the kernel/mesa/firmware bump alone. Happy to provide logs or run a controlled test if useful.

[filip-spaldon]

Update: bisected to linux 7.1.3 + dual-monitor boot dependency found

Thanks for the input — that's very helpful data points. I've made significant progress narrowing this down.

Dual-monitor boot dependency

I've also discovered a critical reproduction condition that explains why it may not trigger for others:

The crash only occurs when both monitors are connected during boot. My setup:

• HDMI-A-1: LG SDQHD 2560x2880@60
• DP-3: GIGA-BYTE M27Q 2560x1440@170

Scenario	Result
Both monitors connected during boot → DPMS off	Crash
HDMI disconnected during boot, then hotplugged after login → DPMS off	No crash
Only DP-3 connected during boot → DPMS off	No crash

This strongly suggests the issue is in amdgpu's DCN 3.5.1 dual-CRTC initialization path during boot on kernel 7.1.x. When both CRTC pipelines are initialized at boot time, something leaves the GPU in a state where a subsequent dpms off (which calls optc35_disable_crtc / link_set_dpms_off internally) hangs the SMU/DMUB and hard-resets the system. When only one CRTC is initialized at boot, DPMS off works fine — and hotplugging the second monitor after boot takes a different code path that doesn't trigger the bug.

No amdgpu/SMU/VPE/CRTC error is ever logged before the crash — the journal just stops mid-stream, consistent with a silent hard hang before the driver can emit a timeout message.

Happy to test kernel parameters (amdgpu.dcdebugmask=0x10, amdgpu.gpu_recovery=1, amdgpu.sg_display=0) on 7.1.3 with dual monitors if that would help narrow down the root cause further.

[dhh]

I've tried to reach out to AMD to see if we can get some eyes on this.

[grhoades]

I can definitely reproduce the issue on my Framework Desktop, As indicated a simple kernel downgrade solved the problem. I have three displays and if active at boot the condition is definitely always present.

❯ fastfetch --logo none --structure host:cpu:gpu:memory:disk:battery
Host: Desktop (AMD Ryzen AI Max 300 Series) (A6)
CPU: AMD RYZEN AI MAX+ 395 (32) @ 5.19 GHz
GPU: AMD Radeon 8060S Graphics [Integrated]
Memory: 15.98 GiB / 125.08 GiB (13%)
Disk (/): 744.79 GiB / 3.64 TiB (20%) - btrfs
❯ omarchy version
3.8.3