TrueNAS is running on bare metal.
I have tried running it on proxmox, but the first try was with proxmox installed on ZFS, which was not a good idea. Proxmox and TrueNAS VM were fighting for the cache memory and proxmox regulary shut down the vm due to lack of memory. After reinstalling proxmox on EXT4, everything was running smooth until these random crashes started, so I changed the configuration to “TrueNAS on bare metal”.
Also consider to decrease a bit the RAM speed: i well remember some old thread where people with your same combination (same CPU , similar motherboard) reach stability just lowering RAM speed!
My experience with chinese motherboard reseller Is to not trust them too much. But neither Intel Is full trustable in this specific case 
the limitation Is more marketing…
btw RAM size shouldnt be you problem
N100 supports IBECC, which is shown in your dmesg output:
[ 15.280751] EDAC MC0: Giving out device to module igen6_edac controller Intel_client_SoC MC#0: DEV 0000:00:00.0 (INTERRUPT)
Sometimes it is more convenient and easier to have tools easily accessible from one place. As an example you can use ventoy; download, install it on a USB stick, and install (simply copy a live boot iso of a Linux distro into the correct folder on ventoy and also copy a downloaded copy of memtest86 iso into the ventoy folder. Boot the computer/server with the ventoy usb stick and select what you wish to do from the menu. You can select to boot into the live Linux distro and after the distro is booted, download and then run the Prime95 application. The memtest86 iso file can be selected and run from the ventoy menu just like it was intended to be and the system will reboot into the memory test. The current free version of memtest86 does support UEFI.
This means there is nothing to try to install or make run in Truenas but you can’t run truenas while using ventoy. One operating system at a time on the hardware applies here too.
I did the memtest86 and prime95 tests and they were all successful. No errors after 10 hours of memtest and CPU temperature did not get higher than 65°C during stress testing (had a look on CPU load and temperature with htop).
Next thing I’ll try is the RAM speed as recommended, “just” need to search for the right setting in the mess of the BIOS settings…
The MemTest86+, was that 5 or more complete passes?
The CPU Stress test is good that it peaked at 65C, while I haven’t looked it up, the CPU may be throttling to save itself from burning up. If you ran this for about 4 hours, then you should have heat saturated the motherboard in that area which results in checking for bad solder joints.
given that memtest not raise any error, i find unlikely that lowering the ram speed will help 
also find unlikely that can be a PSU problem at this point.
I also think to have find that the NIC is an Intel i226 one (to avoid driver related problem).
I would start dig deeper into the bios settings, trying disabling c-states and other power management, and see if something change (not only on the electric bill )
memtest was 4 passes - seems to be the standard config and my screen seems to be to small (800x600) to show everything. Within the test selection screen, I can scroll with the cursor out of the screen, it looks like there is more I don’t see…
Prime95 ran for 3 hours, but I’ll run it over night this evening.
I think those N100 boards are not supposed to suck any unneccessary power - average power consumption during the last year was 42Wh, even with 6 HDDs with no spin-down and a fan running at full speed all the time, so electric bill is not an issue 
…
I went through the C-states already some time ago and I think I’ve disabled any power saving, but I cannot be sure, because this “chinese bios” has a lot of settings I have no clue what they are.
if i may say… i would expect a bit better honestly from a system like that, but It’s a rather pointless discussion because we don’t know how the system being used but maybe there, the 4 nic made a difference (i have bios disabled the unused one). BTW sorry for the degression
if you want, try share some photo, maybe more seasoned users can find something not well setup.
But if you have already disabled everything, i’m sorry to say that i’m out of option 
and maybe the culprit is some incompatibility with the TN kernel
I have similar issues with a chinese N150 board, 16 gb of (tested) RAM.
Tried to remove integerated GPU/VGA output, set a fixed IP (I though it could be related to the NIC going down), no luck. Also nothing special in the logs/journals before the hang.
Last thing I’ve tried is to removing sleep states. To avoid messing with the BIOS (it’s indeed confusing), I have a small service running at start:
[Unit]
Description=Disable deep CPU C-states (C6/C8/C10)
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c ’for s in /sys/devices/system/cpu/cpu*/cpuidle/state*/name; dod=$(dirname “$s”); n=$(cat “$s”);if [[ “$n” == “C6” || “$n” == “C8” || “$n” == “C10” ]]; then echo 1 > “$d/disable”; fi;done’
[Install]
WantedBy=multi-user.target
Then enable the service (systemctl enable --now disable-deep-cstates.service).
No need to reboot, you can check it with cpupower idle-info
Everything above C5 should be DISABLED
C1E:
Flags/Description: MWAIT 0x01
Latency: 2
Usage: 102839989
Duration: 654497639439
C6 (DISABLED) :
Flags/Description: MWAIT 0x20
Latency: 195
Usage: 2889
Duration: 2225003
C8 (DISABLED) :
Flags/Description: MWAIT 0x40
Latency: 260
Usage: 3195
Duration: 4431694
C10 (DISABLED) :
Flags/Description: MWAIT 0x60
Latency: 660
Usage: 10863
Duration: 125296196
I have an updtime of 7 days so far, I will post if it happens again (fingers crossed)
Good point. I’ve checked this and the output does not look like C-States are disabled:
# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
Number of idle states: 5
Available idle states: POLL C1E C6 C8 C10
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Residency: 0
Usage: 207192
Duration: 14663668
C1E:
Flags/Description: MWAIT 0x01
Latency: 2
Residency: 4
Usage: 18021340
Duration: 5376548994
C6:
Flags/Description: MWAIT 0x20
Latency: 195
Residency: 585
Usage: 3347818
Duration: 1950231873
C8:
Flags/Description: MWAIT 0x40
Latency: 260
Residency: 1040
Usage: 1022207
Duration: 1481857152
C10:
Flags/Description: MWAIT 0x60
Latency: 660
Residency: 1980
Usage: 2934330
Duration: 40693201568
I’ll try the soulution you’ve proposed…
Something is not working.
# systemctl status disable-deep-cstates
× disable-deep-cstates.service - Disable deep CPU C-states (C6/C8/C10)
Loaded: loaded (/etc/systemd/system/disable-deep-cstates.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Thu 2026-01-15 08:42:59 UTC; 9min ago
Main PID: 40885 (code=exited, status=127)
CPU: 5ms
Jan 15 08:42:59 hades systemd[1]: Starting disable-deep-cstates.service - Disable deep CPU C-states (C6/C8/C10)...
Jan 15 08:42:59 hades bash[40885]: s: line 1: ’for: command not found
Jan 15 08:42:59 hades systemd[1]: disable-deep-cstates.service: Main process exited, code=exited, status=127/n/a
Jan 15 08:42:59 hades systemd[1]: disable-deep-cstates.service: Failed with result 'exit-code'.
Jan 15 08:42:59 hades systemd[1]: Failed to start disable-deep-cstates.service - Disable deep CPU C-states (C6/C8/C10).
Any idea?
After googling a bit, I found a post about the max_cstate file
/sys/module/intel_idle/parameters/max_cstate
which contains “9” on my system. Would it be an option to set this to “5”?
max_cstate didn’t worked for me, but maybe it will for you?
It might be a c/c issue, here is a clean paste:
C6 and above are now disabled - that worked, many thanks!
let’s see how long the system will be up…
I hope the Gael solution’s will resolve every issue.
The same, i have to admit (just for the sake of conversation) that the fact the deep C-states need to be crippled on a platform intended to run as a low power NAS is concerning
In your place, I’d raise this issue with the vendor… they might be able to provide a more stable BIOS update?
FWIW, I have a CWWK motherboard with N150 CPU and 16GB RAM, and was getting random lockup-crashes (system just becomes unresponsive after running for about a day, snow artifacts on HDMI output but no error in the logs or anything). I wrote to the motherboard manufacturer and did all the troubleshooting they asked for, nothing helped and nothing pointed in a specific direction. I even updated the BIOS because some reports said the newer version fixed some instability. The RAM passed 5 passes of memtest86 multiple times.
My RAM is rated at 4800MHz, and on a whim I lowered it to 4200MHz. No random crashes since then. So that’s what I’m going to stick with. I don’t understand why memtest86 did not reveal the problem, but there you are.
Just thought I’d share my experiences. Hope this helps.
System is now running for a week without any issue.
I want to keep it running for at least four weeks, before I do another change, but I’ll try changing the RAM speed then…
I am glad to read you have likely identified the problem but not happy to read that Memtest86 did not find it. Was it Memtest86 or Memtest86+ that you used?
Nope they are not the same. If you retest, try the other one. Free version of course.
Hmmm, I vaguely recall DRAM refresh happening during accesses. I wonder if Memtest86(+)s activity caused the DRAM cells to be refreshed enough that the problem was not detectable.
I would guess that normal memory activity does spend some time in CPU caches. That might allow the DRAM cells to loose enough charge that bits flipped. But, a DRAM test constantly accesses the DRAM, so perhaps it indirectly causes enough refreshes to prevent those bit flips.
Then, at lower DRAM speeds, the CPU & DRAM refreshes have less contention. So fewer or no problems.
Anyway, take it for what it’s worth… 2nd / 3rd hand knowledge.