Yes, my multimeter shows right values in PSU pines. Thanks!
12gen N-series Nas motherboard (topton, cwwk, ... )
- Thread starter Steffe
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
I'm on the verge of replacing my N5105 china board with the purple N150, mainly to get access to the AVX instruction that I need for a program update. This is a Unraid server that mainly runs 24/7
It seems with some tweaking a decent replacement? My PSU is a Corsair SF450 Platinum (~75% efficient at 20w) and will have 5 SATA drives and 1 NVME that's compatible with ASPM
It seems with some tweaking a decent replacement? My PSU is a Corsair SF450 Platinum (~75% efficient at 20w) and will have 5 SATA drives and 1 NVME that's compatible with ASPM
Hi all, I have a green board from Kingnovy that showed the usual problems cited here of hanging after a day or 2. After a few months it wouldn't power on. It's almost impossible to RTM from here with customs etc so I brought it to my repair guy who said it had excess / sloppy thermal paste application which was the cause of the failure. He cleaned it up and it's now running again but with the same old hanging problem.
This is the screen when it hangs. Using a portable monitor as having trouble with my gaming monitor on DP and HDMI with it. I've tried all the bios tweaks recommended here but the bios quits before I can save. c-states are turned off.
It has a 16gb stick of crucial ram in it.
I also have a purple one that had the same issues until I put a 32gb Samsung stick in, turned off c-states and it runs perfectly.
My question is, should I swap the crucial for samsung in the green one or are there other things I should try instead / before I do that.
This is the screen when it hangs. Using a portable monitor as having trouble with my gaming monitor on DP and HDMI with it. I've tried all the bios tweaks recommended here but the bios quits before I can save. c-states are turned off.
It has a 16gb stick of crucial ram in it.
I also have a purple one that had the same issues until I put a 32gb Samsung stick in, turned off c-states and it runs perfectly.
My question is, should I swap the crucial for samsung in the green one or are there other things I should try instead / before I do that.
Hi,
Maybe it is due to a bug in the ASM1166-Chip? - But it´s only an Idea...
(check dmesg - on my board i see 0-31 SATA-Ports)
I have:
- latest Bios: 紫色-N355-CW-NAS-ADLN-K-20250425.iso
(Source: https://forums.servethehome.com/ind...nas-motherboard-topton-cwwk.42432/post-467996)
- and latest ASM-Firmware: 2024.12 - Version 241224-0000-00 - 12240000
(Source: Asmedia ASM-2116/116x Sata 6G Controller Firmware Version 12240000)
...and the ASM1166-bug is still there.
Background:
211873 – ASM1166: too many SATA ports detected
Workaround:
dmesg-output (attention to: 0000:03:00.0 and 30/32 ports):
Code:
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: version 3.0
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: enabling device (0000 -> 0002)
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: SSS flag set, parallel bus scan disabled
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: 30/32 ports implemented (port mask 0xffffff3f)
Oct 02 18:47:06 kernel: ahci 0000:03:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst
Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=force pti=off ahci.mask_port_map=0000:03:00.0=0x3f pcie_aspm.policy=powersupersave enable_guc=3"If its a green board labelled BKHD_ (or probably also MW_) then based on many threads I've read they detest Crucial but really like Samsung (or Hynex if you can get it). If it's a CW_ label (ie. From CWWK) then they really love Crucial.
As with the chinese mini pcs some boards had too big a gap between the shim/heatsink and the cpu so even good paste struggles since it can a) flow out and b) is meant to be microns thick during use. There was some success in using Arctic's TP3 thermal pads. It can also be stacked up to 3 layers so it's handy to buy one thickness and bulk it up if poor contact. It's meant to compress to work well.
Anecdotally some PC power supplies appear to struggle with the low loads of these types of devices as even a (say) 500w supply expects to be asleep or running well above 100w. Also people often reuse an older psu which may add to instability. Though ironically new low wattage supplies are rare. Some people have swapped psu and gained good long term stability.
Thanks for this Kevin,
It's a MW-N100-NAS board.
I'll get a Samsung or Hynix stick in the first instance, if that doesn't work I'll get the Arctic TP3s.
I've already had 2 brand new 300 & 350w PSUs on it so far without success.
Took the plunge on the purple durple. Getting to C8 with the tweaks mentioned here.
Was having issues booting past C6 with Unraid but updating to the latest bios (April 2025) and the C states set to auto fixed it. DIdn't try C10 like mentioned though.
Here is my go file for those in Unraid. I am sure there are more tweaks to be had:
Was having issues booting past C6 with Unraid but updating to the latest bios (April 2025) and the C states set to auto fixed it. DIdn't try C10 like mentioned though.
Code:
Pkg(HW) | Core(HW) | CPU(OS) 0
| | C0 active 5.6%
| | POLL 0.0% 0.0 ms
| | C1E 6.3% 0.4 ms
C2 (pc2) 7.0% | |
C3 (pc3) 2.8% | C3 (cc3) 0.0% |
C6 (pc6) 18.3% | C6 (cc6) 85.3% | C6 7.9% 0.8 ms
C7 (pc7) 0.0% | C7 (cc7) 77.6% |
C8 (pc8) 30.1% | | C8 5.9% 3.0 ms
C9 (pc9) 0.0% | |
C10 (pc10) 0.0% | |
| | C10 74.0% 6.6 ms
| Core(HW) | CPU(OS) 1
| | C0 active 10.4%
| | POLL 0.0% 0.0 ms
| | C1E 2.6% 0.4 ms
| |
| C3 (cc3) 0.0% |
| C6 (cc6) 86.1% | C6 6.5% 0.8 ms
| C7 (cc7) 79.7% |
| | C8 4.7% 3.0 ms
| |
| |
| | C10 75.6% 8.7 ms
| Core(HW) | CPU(OS) 2
| | C0 active 7.4%
| | POLL 0.0% 0.0 ms
| | C1E 2.3% 0.4 ms
| |
| C3 (cc3) 0.0% |
| C6 (cc6) 88.5% | C6 12.7% 0.9 ms
| C7 (cc7) 76.4% |
| | C8 1.3% 2.6 ms
| |
Code:
#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp
# -------------------------------------------------
# Set power-efficient CPU governor
# -------------------------------------------------
/etc/rc.d/rc.cpufreq powersave
# -------------------------------------------------
# Disable CPU Turbo
# -------------------------------------------------
[[ -f /sys/devices/system/cpu/intel_pstate/no_turbo ]] && echo "1" > /sys/devices/system/cpu/intel_pstate/no_turbo
[[ -f /sys/devices/system/cpu/cpufreq/boost ]] && echo "0" > /sys/devices/system/cpu/cpufreq/boost
# -------------------------------------------------
# Enable power-efficient ethernet
# -------------------------------------------------
# enable IEEE 802.3az (Energy Efficient Ethernet): Could be incompatible to LACP bonds!
# Disable wake on lan
for i in /sys/class/net/eth?; do ethtool -s $(basename $i) wol d; done
# -------------------------------------------------
# powertop tweaks
# -------------------------------------------------
# Enable SATA link power management (this skips SATA host5)
echo med_power_with_dipm | tee /sys/class/scsi_host/host*/link_power_management_policy
# Runtime PM for I2C Adapter (i915 gmbus dpb)
echo auto | tee /sys/bus/i2c/devices/i2c-*/device/power/control
# VM writeback timeout
for i in /proc/sys/vm/dirty_writeback_centisecs; do
echo '1500' > $i
done
# Autosuspend for USB device
echo auto | tee /sys/bus/usb/devices/*/power/control
# Runtime PM for disk
echo auto | tee /sys/block/sd*/device/power/control
# Runtime PM for PCI devices
echo auto | tee /sys/bus/pci/devices/????:??:??.?/power/control
# Runtime PM for ATA devices
echo auto | tee /sys/bus/pci/devices/????:??:??.?/ata*/power/controlWhat is the actual power consumption? What C state is reported is irrelevant if the hardware isn't actually using that C state, we need to know the actual power usage.
Have you tested any solution so far?
I purchased an additional RAM module (Integral – DDR 4800Mhz), but the system continued to experience freezes.
Currently, I am running with Crucial DDR5 5600Mhz RAM, and the issue persists. The freezes are now less frequent, occurring approximately every 7–10 days.
However, the problem remains: the system freezes randomly, and I am forced to physically access the server to perform a manual power cycle (shutdown and restart)
Hi everyone,
I’d like to share my experience with the Topton BKHD-1264-NAS N150 board, which I recently tested as a replacement for my nearly 10-year-old J3710 system. The J3710 had suddenly become unstable, crashing and resetting several times a day. Rather than troubleshooting it in depth, I decided to move on and look for a modern, low-power replacement.
I picked up the N150 NAS board (with 16GB DDR5 and a 128GB NVMe) from AliExpress for around €165 (including discounts and tax). My expectation was to get a noticeably more powerful platform while keeping power consumption in a similar low range.
To avoid memory compatibility issues, I ordered the baseboard bundled with RAM. The NVMe wasn’t optional, but I swapped it out immediately for a 1TB Corsair drive I already had. After connecting two SATA SSDs, the system was ready to go.
Installing Debian 13 was smooth, and I quickly set up my usual Dockerized services (Plex, Inventree, Seafile). Everything worked fine - until I started checking power consumption.
To my surprise, idle power never dropped below 20W, which I consider high for a small NAS system. Using powertop, I saw that the CPU package C-state was stuck at C3. After some research, I discovered the well-known issue with JMB58x controllers not supporting ASPM, which blocks deeper power states.
My plan was to disable the onboard controller and, if needed, later add a more efficient one via the PCIe slot. I tried removing the device in Linux (echo 1 > /sys/bus/pci/devices/<device>/remove) and forcing ASPM with the “enable-aspm” script, but the package still wouldn’t go beyond C3.
Digging deeper, I learned about hidden BIOS settings:
Chipset → System Agent (SA) Configuration → Graphic Configuration → Yellow Screen Workaround → ENABLED
Once enabled, I was able to:
Unfortunately, power measurements only dropped by about 3–4W, bringing the idle consumption down to 16–17W. Not the 5-10W I had hoped for.
So my question is: Is there anything else I can do, or is this Topton board simply not capable of running as a truly power-efficient NAS?
I’d like to share my experience with the Topton BKHD-1264-NAS N150 board, which I recently tested as a replacement for my nearly 10-year-old J3710 system. The J3710 had suddenly become unstable, crashing and resetting several times a day. Rather than troubleshooting it in depth, I decided to move on and look for a modern, low-power replacement.
I picked up the N150 NAS board (with 16GB DDR5 and a 128GB NVMe) from AliExpress for around €165 (including discounts and tax). My expectation was to get a noticeably more powerful platform while keeping power consumption in a similar low range.
To avoid memory compatibility issues, I ordered the baseboard bundled with RAM. The NVMe wasn’t optional, but I swapped it out immediately for a 1TB Corsair drive I already had. After connecting two SATA SSDs, the system was ready to go.
Installing Debian 13 was smooth, and I quickly set up my usual Dockerized services (Plex, Inventree, Seafile). Everything worked fine - until I started checking power consumption.
To my surprise, idle power never dropped below 20W, which I consider high for a small NAS system. Using powertop, I saw that the CPU package C-state was stuck at C3. After some research, I discovered the well-known issue with JMB58x controllers not supporting ASPM, which blocks deeper power states.
My plan was to disable the onboard controller and, if needed, later add a more efficient one via the PCIe slot. I tried removing the device in Linux (echo 1 > /sys/bus/pci/devices/<device>/remove) and forcing ASPM with the “enable-aspm” script, but the package still wouldn’t go beyond C3.
Digging deeper, I learned about hidden BIOS settings:
Chipset → System Agent (SA) Configuration → Graphic Configuration → Yellow Screen Workaround → ENABLED
Once enabled, I was able to:
- Force ASPM mode on all PCIe root ports
- Disable the PCIe bus connected to the JMB58x controller, preventing it from interfering with ASPM
Unfortunately, power measurements only dropped by about 3–4W, bringing the idle consumption down to 16–17W. Not the 5-10W I had hoped for.
So my question is: Is there anything else I can do, or is this Topton board simply not capable of running as a truly power-efficient NAS?
These boards are made cheap and lack any power optimisation. Just because it is spending time in high C-States, doesn't mean its actually doing so, as often what is reported by the OS is what it is requesting or hinting at C-State wise, and not the actual C-State the hardware is in.
I can't know for sure as Intel reference designs and white papers are not publicly available, but I suspect there are a couple of Intel reference designs for these types of SoC. One is minimal DC power rails with a reduced BOM (Bill of Materials) so cheaper to make, and another using more DC power rails allowing the package greater flexibility to power down various parts of the SoC (better power gating), and/or reduced voltages. If that is the case, you know very well what cheap direct from China stuff will be using.
I must admit to be wrong about the cause of my problems with the cwwk purple nas board:
I bought a second cwwk purple from Amazon with best warranty extension available. And it did not work either.
Then decided to risk buying a new psu, a really cheap cosair rm650e from Amazon and I was shocked: the new board worked with the relatively cheap corsair psu but not with the fractal ion+ 2. So I wired the "defect" old board to the new corsair psu... It worked.
So, shame on me for blaming cwwk. The fault is with my fractal psu... and me for not checking by buying a second psu. Having a defect with a high prices psu, that I thought was impossible.
I bought a second cwwk purple from Amazon with best warranty extension available. And it did not work either.
Then decided to risk buying a new psu, a really cheap cosair rm650e from Amazon and I was shocked: the new board worked with the relatively cheap corsair psu but not with the fractal ion+ 2. So I wired the "defect" old board to the new corsair psu... It worked.
So, shame on me for blaming cwwk. The fault is with my fractal psu... and me for not checking by buying a second psu. Having a defect with a high prices psu, that I thought was impossible.
Replacing with Samsung RAM worked, been up for over 2 weeks without a glitch.
Thanks to all on this thread for putting me right.
THANK YOU for this. I was stuck with USB 3.0 devices running at USB 2.0 speed for the longest time. Could not figure out what was wrong.
You solution works like a charm on my CW-NAS-ADLN-K N100 "purple" mobo. I set the USB legacy to "auto" and then "D3 cold" to disabled and this fixed the problem. Btw in my BIOS the D3 cold setting is not in the TCSS submenu but directly under SA configuration.
Bus 002 Device 002: ID 1058:2621 Western Digital Technologies, Inc. Elements 262
1
Negotiated speed: SuperSpeed (5Gbps)Also for some reason the front USB port of my Jonsbo N2 refuses to negotiate speeds higher than USB 2.0 (480 Mbps). I have no idea if I am the only one having that issue but that pretty annoying. All in all I only have one functional USB 3.0 port :-/
Interesting. I feel I've seen other posts (here or on reddit) where a quality psu struggled to drive an N100 type board. My hypothesis is that good high wattage supplies can be surprisingly bad at managing the low but fluctuating demand on an N100 type device. Even your new psu is so over specified even if someone added say 8 x 7200 drives to a board like this. Last time I looked it was hard to find anything new around say 300w.
What RAM brand & spec are you using? CWWK boards really like crucial.
Other thought is psu. See kobold81 posts.
Good morning,
I’m experiencing the same issue, but in my case, the server is running unRAID as the operating system. The behavior is identical: the system freezes completely, becomes unreachable via the web interface or SSH, and even stops responding to ping requests. The only way to recover is to perform a hard reboot.
I’ve tested multiple RAM modules, several USB flash drives (since unRAID runs from a USB device), and a wide range of configuration settings, but the problem persists.
At this point, the only components left to test are the SSD and the power supply unit (PSU).