Quinta

It appears your server experienced a "hard" reboot during heavy ZFS write operations. The potential causes: RAM Instability (XMP/DOCP): Sustained 10GbE transfers at 600-700 MB/s put extreme pressure on the memory subsystem. Your syslog shows 4/4 memory slots populated. On Z390 motherboards with an i9-9900K, running four sticks of RAM with XMP enabled can be unstable. Try disabling XMP or dropping the frequency slightly. ZFS ARC and Memory Pressure: ZFS uses a significant portion of RAM for its Adaptive Replacement Cache (ARC). Under heavy parallel rsync load, if the ARC doesn't release memory fast enough, the Linux kernel's Out-Of-Memory (OOM) killer might trigger, occasionally leading to a system hang or reboot if a critical process is affected. Thermal Protection: While you suspected HDD thermal throttling, that usually leads to slow performance rather than a reboot. However, a VRM or CPU overheat on the ASUS ROG MAXIMUS XI HERO during long-duration high-throughput tasks can trigger a hardware-level thermal shutdown. Potential fixes: Check for "C-States" Issues: Some Intel/ASUS combinations are sensitive to deep sleep states. In your BIOS, try setting Typical Current Idle or disabling C-States to see if stability improves during high-load transitions. Limit ZFS ARC: To prevent potential OOM issues, you can limit the maximum size of the ZFS ARC by adding zfs_arc_max to your sysctl settings or boot parameters.

Hi all, I've been doing some power efficiency tuning on my Unraid 7.2.3 server and ran into what appears to be a kernel-level limitation. Wanted to document my findings and see if anyone else with Arrow Lake hardware has run into this and found a workaround. System specs: - CPU: Intel Core Ultra 5 225 (Arrow Lake, family 0x6, model 0xc6, stepping 0x2) - Motherboard: ASUS Z890M Plus WiFi - RAM: 24GB DDR5 - Unraid version: 7.2.3 - Kernel: 6.12.54-Unraid The problem: Despite having all C-states properly configured in BIOS (Package C State Limit = C10, Enhanced C-states = Enabled, CPU C-states = Enabled), powertop only shows C1/C2/C3 ACPI states. C6, C8, and C10 are never reached. Diagnostics: The cpuidle states exposed are all ACPI FFH MWAIT rather than native intel_idle states: /sys/devices/system/cpu/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state1/desc: ACPI FFH MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc: ACPI FFH MWAIT 0x21 /sys/devices/system/cpu/cpu0/cpuidle/state3/desc: ACPI FFH MWAIT 0x60 The intel_idle driver is active (cat /sys/devices/system/cpu/cpuidle/current_driver returns intel_idle) but produces no initialization messages in dmesg beyond echoing the kernel command line. It is compiled into the kernel, not a loadable module: find /lib/modules/$(uname -r) -name "intel_idle*" returns nothing. dmesg confirms the CPU is identified correctly: smpboot: CPU0: Intel(R) Core(TM) Ultra 5 225 (family: 0x6, model: 0xc6, stepping: 0x2) However, intel_idle has no native C-state table entry for model 0xc6 in kernel 6.12, causing it to silently defer to the ACPI Cpu0Cst table, which only exposes C3 as the deepest state. Steps already taken (none resolved the issue): - BIOS: ASPM fully enabled (L1, L1.1, L1.2 on all PCIe sections) - BIOS: VMD controller disabled and confirmed absent from dmesg - Kernel parameter intel_idle.max_cstate=9 added to syslinux.cfg (confirmed in /proc/cmdline) - powertop --auto-tune run at boot via user script My best explanation so far: Arrow Lake desktop (model 0xc6) support was added to the intel_idle driver in kernel 6.13. Unraid's current kernel 6.12.54 predates this, so intel_idle falls back to ACPI C-state definitions which cap at C3. Has anyone else with Arrow Lake or Core Ultra 200 series hardware run into this? Were you able to work around it, or are you also stuck waiting on a kernel update? Any input appreciated!