[Tahoe.26] Kernel panic: Unexpected SoC watchdog reset (OpenZFS 2.3.1-rc1)

[iadev09]

I was testing OpenZFS 2.3.1-rc1 on macOS 26.0.1.
After a successful build operation, the system rebooted unexpectedly with a SoC watchdog panic.

---

System Information

Type	Version / Name
OS / Distribution	macOS 26.0.1 (25A362)
Architecture	arm64 (Apple Silicon, Mac15,9)
Kernel Version	Darwin 25.0.0
OpenZFS Version	zfs-2.3.1-rc1 / zfs-kmod-2.3.1-rc1
Install Method	RC .pkg build from OpenZFS on OS X
Boot / Root Pool	**

---

Explanation

Before upgrading to macOS Tahoe, I had already started noticing problems under the Sequoia release. The system showed abnormally high latency. Honestly, I had almost forgotten there was even a ZFS volume involved — I was using an early JetBrains RustRover build and initially thought the lag came from Java. It took me quite a while to realize the real bottleneck was inside the filesystem itself.

Still, I never experienced a full kernel panic on Sequoia. Occasionally I unloaded and remounted the pool manually, which temporarily restored responsiveness. Later I realized I hadn’t updated the driver for that OS version either.

After upgrading to Tahoe, everything mounted cleanly, and file I/O worked without visible issues.
But with OpenZFS 2.3.0, whenever I ran cargo — specifically during its async build phase 🦀 — the build would never complete. A kernel panic would occur every time.
Interestingly, none of the panic reports explicitly mentioned ZFS. Just before the panic, the mouse froze completely, and the logs contained interrupt-related traces that looked more like Wi-Fi or Bluetooth driver activity.

With the pre-release 2.3.1-rc1, I could finally clean the target directory — something impossible before. I excluded heavy folders (node_modules/, target/, vendor/, etc.) while copying my workspace and managed to build successfully.
However, running cargo --fix brought the black screen back once again — another panic.

I suspect the async builder might be exposing a subtle concurrency edge case — maybe someone, somewhere, missed a future 😄
(This time it’s not me.)

The attached diagnostic reports contain all relevant information.
I hope this helps your exceptional work on OpenZFS.

---

Panic Summary

bug_type: 210
panicString: Unexpected SoC (system) watchdog reset occurred after panic diagnostics were completed
kernel: Darwin Kernel Version 25.0.0
org.openzfsonosx.zfs (2.3.1)

---

Included Diagnostic Archive

Attached: zfs-diag-YYYYmmdd-HHMMSS.tgz

Contents:

• Sanitized panic.json
• system.txt (macOS + kernel info)
• zfs-version.txt
• zpool-status.log
• zpool-events.log
• zfs-pool-info.log
• kernel-zfs.log

---

Additional Notes

• Spotlight indexing may have been active during the event
• The pool uses only standard feature flags (no experimental features)
• Rebooted successfully; zpool scrub reports no errors
• Panic report collected via report_bug.sh

Internal Reference: Tohoha.26

zfs-diag-20251009-192850.tgz

[rottegift]

This is very likely the vnop_pageout_v2 problem which we isolated and identified in the past couple of days and which lundman has commited an apparent fix for. Roughly, macos26 tahoe on a platform that supports the secure page table monitor (which watches the running kernel for page table violations) panics if we don't set the default protection level on the range of pages we are paging out. That is done via a since-macOS 12 kernel function that we hadn't started using because nothing was enforcing on fine page-range protections (in the sense of read/write/execute of VM pages and in particular write xor execute).

Keep your eye out for the next 2.4.1 build (or a backport to 2.3.1).