Nicola NicodemoItaliano

Hunting random resets: the Snapdragon X DC ZVA erratum

11 November 2026

On 22 October my Galaxy Book4 Edge (Snapdragon X Elite) went black and rebooted while I was using it. It happened again on 29 October, and on 1 November the screen froze first, with Chrome open, then the machine reset.

Every time it was the same: no kernel panic, nothing in the journal, and the clock back at 29 May 2024. That last detail is the useful one. The real-time clock lives in the power management chip, so the PMIC itself had gone down. This wasn’t Linux crashing; something below it pulled the plug.

Logging what isn’t logged

The first step was to make sure I wasn’t missing anything. I added a small service that keeps a plain-text copy of the journal for every boot, written out continuously. It worked: it captured about 30 seconds more than the normal journal. Those 30 seconds held no clue either.

The lead

Searching for “hard reset, nothing logged” on X1E turned up three things that described exactly this:

  • x1e-crash, a tiny program that resets X1E machines by running the DC ZVA instruction (zero a block of memory) right after a CPU cluster wakes from its deepest idle state, CL5
  • Jens Glathe’s patch “hamoa: Drop cluster_cl5 idle state”, suggested by Marc Zyngier as a stop-gap
  • an Ubuntu bug on a ThinkPad T14s resetting every few hours

DC ZVA is everywhere: memset() and the kernel’s page clearing use it, so normal use runs it constantly.

Reproduced

On 1 November I ran x1e-crash once, after a sync. The machine froze and reset within seconds, and the clock came back at 29 May 2024: the same signature as the three resets. That’s as close to proof as a reproducer gets.

The fix that keeps CL5

Dropping CL5 works, and it’s what some kernels do, including Omarchy’s. But CL5 is the cluster idle state the platform’s deepest sleep states are defined around, so I wanted to keep it and remove the instruction instead:

  • Patch 1 (host): clear SCTLR_EL1.DZE, so DC ZVA from user space traps to the kernel, and emulate it there with ordinary stores. The kernel’s own clear_page, memset and MTE paths never use DC ZVA. This is x1e-sleep’s version of Marc Zyngier’s erratum workaround for Oryon cores.
  • Patch 2 (KVM guests): set HCR_EL2.TDZ for every virtual CPU, so a guest sees DC ZVA as unavailable, and any guest that runs it anyway gets an undefined-instruction exception instead of resetting the host.

Verified

  • the boot log reports CPU features: detected: Broken DC ZVA, and user space reads DCZID_EL0 with the “prohibited” bit set
  • x1e-crash, which used to reset the machine within seconds, ran all 10,000 rounds (61 minutes) and exited cleanly
  • in a Debian VM it dies immediately with SIGILL, the host logs “Unsupported guest access” and stays up

The patches are 0043 and 0044 in book4-edge-linux (tools/kernel/sleep-backport/), on the book4/7.2-sleep branch of my kernel fork. No awake reset since 1 November, so far.

I did this work, and wrote this post, with the help of AI (mostly Claude Code). Every result here was measured on the laptop itself.

← All posts