Last active 1788293786

ZZ's Avatar ZZ revised this gist 1788283977. Go to revision

1 file changed, 4 insertions, 2 deletions

Gemini-ZFS-Fix.md

@@ -1,7 +1,9 @@
1 - - Root Cause 1 (Kernel Panic): An interface bug between Linux Kernel 6.18 code allocation profiling hooks (CONFIG_MEM_ALLOC_PROFILING) and the out-of-tree OpenZFS driver module. Background ZFS I/O workers drop pointers during slab memory cleanups, triggering __alloc_tagging_slab_free_hook page faults.
1 + When you have 128 GB of RAM, ZFS defaults to a 64 GB ARC max ceiling. If your Windows VM pins 96 GB via hugepages, your system is mathematically trying to commit 160 GB of RAM on a 128 GB physical machine.
2 + Since hugepages cannot be unpinned, the host kernel starves, leading directly to the brutal cascading page faults and segmentation faults you experienced.
2 3
4 + Technical Case Notes:
5 + - Root Cause 1 (Kernel Panic): An interface bug between Linux Kernel 6.18 code allocation profiling hooks (CONFIG_MEM_ALLOC_PROFILING) and the out-of-tree OpenZFS driver module. Background ZFS I/O workers drop pointers during slab memory cleanups, triggering __alloc_tagging_slab_free_hook page faults.
3 6 - Root Cause 2 (Segfaults / Exit Code 139): Core memory allocation collision. Pinned Windows VM static hugepages (96 GB) combined with default OpenZFS ARC ceilings (50% of host RAM = 64 GB) exceeded physical RAM capacity (128 GB). This starved the host kernel during intensive parallel nixos-rebuild compiler routines, triggering segmentation faults across Python, Sphinx, and VS Code extraction tools.
4 -
5 7 - Neutralize Kernel Allocation Profiling HooksForce the Linux kernel to bypass the unpatched memory tracking hooks that conflict with out-of-tree file system drivers.Action: Upgrade to a fixed minor kernel release (e.g., 6.18.48+) and append alloc_tag_boot=off directly to the boot loader command line parameters.
6 8
7 9 ```

ZZ's Avatar ZZ revised this gist 1788282701. Go to revision

1 file changed, 30 insertions

Gemini-ZFS-Fix.md(file created)

@@ -0,0 +1,30 @@
1 + - Root Cause 1 (Kernel Panic): An interface bug between Linux Kernel 6.18 code allocation profiling hooks (CONFIG_MEM_ALLOC_PROFILING) and the out-of-tree OpenZFS driver module. Background ZFS I/O workers drop pointers during slab memory cleanups, triggering __alloc_tagging_slab_free_hook page faults.
2 +
3 + - Root Cause 2 (Segfaults / Exit Code 139): Core memory allocation collision. Pinned Windows VM static hugepages (96 GB) combined with default OpenZFS ARC ceilings (50% of host RAM = 64 GB) exceeded physical RAM capacity (128 GB). This starved the host kernel during intensive parallel nixos-rebuild compiler routines, triggering segmentation faults across Python, Sphinx, and VS Code extraction tools.
4 +
5 + - Neutralize Kernel Allocation Profiling HooksForce the Linux kernel to bypass the unpatched memory tracking hooks that conflict with out-of-tree file system drivers.Action: Upgrade to a fixed minor kernel release (e.g., 6.18.48+) and append alloc_tag_boot=off directly to the boot loader command line parameters.
6 +
7 + ```
8 + # Disable hugepages before recompiling kernel
9 + sudo sysctl -w vm.nr_hugepages=0
10 + sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
11 + sudo echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
12 + ```
13 +
14 + ZFS Notes
15 + - ZFS ARC Mem Use: `zarcstat # size`
16 + - ZFS ARC Size Floor: `zarcstat # c for floor`
17 + - ZFS ARC Size Ceiling: cat /sys/module/zfs/parameters/zfs_arc_max
18 + - ZFS ARC with alloc 50% of system mem by default, which could crash into a memory hugepage.
19 + - Balance Hugepages and ZFS ARC mem directly via the kernel command line
20 + ```
21 + boot.kernelParams = [
22 + # Balance Hugepage and ZFS ARC mem alloc limits directly via kernel command line
23 + "hugepages=96"
24 + "hugepagesz=1G"
25 + "default_hugepagesz=1G"
26 + "transparent_hugepage=never"
27 + "zfs.zfs_arc_min=4294967296"
28 + "zfs.zfs_arc_max=12884901888"
29 + ]
30 + ```
Newer Older