Sadly I dont have any other systems to test that. They have passed all testing I have been able to through at them and they have been thermally fine, even after a big Immich import.
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.
Well, maybe at least some other nvme drives then, which are not "990 EVO Plus"? All I'm trying to say is that to get any indication of where the problem is - you need to start eliminating the variables from the equation. Trying one drive - yeah, if the result is different that would be at least something.
There are also these 2 years of discussions of a problem that sounds similar.
Last edited:
I got two of these. One is some kind of unbranded green mobo with a N305 and 6 SATA ports and the other one is the white CWWK CW-AT-10G-8P with a N350.
They both seem to have similar AMI BIOS variants.
In both of them, the IBECC feature (In-band ECC) doesn't actually work
You can try to enable it in the BIOS but it won't actually be enabled in the memory controller. The BIOS has a blurb about only enabling it of you have a symmetrical config . Not sure why as from the Intel specs I read this doesn't appear to be a requirement but those CPUs and these boards have only one SO-DIMM so no symmetrical config for you anyway.
The Linux driver thinks it's on but it's not (as indicated by dmidecode). There are multiple issues here such as none of the IBECC registers of the memory controller being accessible... The driver reads all 1's (I hacked it to check) on all register locations which it incorrectly interprets as "enabled".
The BIOS does also fail to properly reserve the memory controller register ranges at offset d800 and d400 in the PNP 03 Device region.
It's all a bloody mess of buggy and poorly configured BIOS and of course you have several vendors who sell the same stuff and have no idea about and will not get any of it fixed.
They both seem to have similar AMI BIOS variants.
In both of them, the IBECC feature (In-band ECC) doesn't actually work
You can try to enable it in the BIOS but it won't actually be enabled in the memory controller. The BIOS has a blurb about only enabling it of you have a symmetrical config . Not sure why as from the Intel specs I read this doesn't appear to be a requirement but those CPUs and these boards have only one SO-DIMM so no symmetrical config for you anyway.
The Linux driver thinks it's on but it's not (as indicated by dmidecode). There are multiple issues here such as none of the IBECC registers of the memory controller being accessible... The driver reads all 1's (I hacked it to check) on all register locations which it incorrectly interprets as "enabled".
The BIOS does also fail to properly reserve the memory controller register ranges at offset d800 and d400 in the PNP 03 Device region.
It's all a bloody mess of buggy and poorly configured BIOS and of course you have several vendors who sell the same stuff and have no idea about and will not get any of it fixed.
Last edited:
Hello,
I have a BKHD-1264-NAS N150 motherboard, with Crucial 16GB DDR5-4800 and Proxmox 9.1.5, kernel 6.17.
It freezes frequently. When in idle it runs for a long time but when transferring data to an attached SATA drive, it freezes after 1-2 hours.
I've tried to run a memtest but the HDMI monitor randomly show a black screen and noise, so I cannot check the results!
I've tried to disable CSTATE but it doesn't help.
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll pcie_aspm=off pcie_aspm.policy=performance nvme_core.default_ps_max_latency_us=0"
Do you I have a defective board or is it a memory compatibility problem? Or linked to the JMB58x SATA controller?
Thanks!
I have a BKHD-1264-NAS N150 motherboard, with Crucial 16GB DDR5-4800 and Proxmox 9.1.5, kernel 6.17.
It freezes frequently. When in idle it runs for a long time but when transferring data to an attached SATA drive, it freezes after 1-2 hours.
I've tried to run a memtest but the HDMI monitor randomly show a black screen and noise, so I cannot check the results!
I've tried to disable CSTATE but it doesn't help.
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll pcie_aspm=off pcie_aspm.policy=performance nvme_core.default_ps_max_latency_us=0"
Do you I have a defective board or is it a memory compatibility problem? Or linked to the JMB58x SATA controller?
Thanks!
The BKHD boards are said to prefer SK Hynex or Samsung DRAM. If you're using something else that might be a factor.
I'd also recommend running some kind of temperature monitoring software. There's been cases where poor quality control could leave the cpu or sata controller overheating. It's fixable but you have to detect it first. There have also been cases where the ATX power supply does weird things at the low current/wattage these kind of boards run at. It's hard to know why but people have got stability after changing PSU.
There was definately (to my eyes) a period where many of the Chinese boards & MiniPCs preferred explicit 4800 dram and didn't cope with slowing say 5600 dram to the board's fixed 4800 speed. If the bios let's you tune the memory timings then, some have found stability by easing the clock to say 4400. If the bios hides those settings then there are usually ways to unlock it. (search the forums).
Thanks for your help.
The CPU never goes over 80°C but I've checked with a thermal camera and there is a chip, between the CPU and SATA ports that goes up to 70°C. The PSU is a Seasonic.
When I plug a keyboard & monitor to enter the BIOS, it randomly shows black screen and sometimes event reboot by itself. I don't find the option to lower memory speed, neither to unlock the BIOS for this BKHD-1264-NAS N150 motherboard.
I will try to get another RAM brand to see if it fix the problem.
The CPU never goes over 80°C but I've checked with a thermal camera and there is a chip, between the CPU and SATA ports that goes up to 70°C. The PSU is a Seasonic.
When I plug a keyboard & monitor to enter the BIOS, it randomly shows black screen and sometimes event reboot by itself. I don't find the option to lower memory speed, neither to unlock the BIOS for this BKHD-1264-NAS N150 motherboard.
I will try to get another RAM brand to see if it fix the problem.
The chip that's getting hot is probably a JMB585 or the ASM1166 or similar. Essentially a PCIe to SATA controller. They're meant to be able to hit ~105c, but are expected to peak around 50-55c. As your seeing 70c on the outside it might be getting hotter internally. On the better boards these chips have a heatsink on them. Also arranging your airflow to hit that heatsink/chip is a good idea.
The Chinese boards can be weird about bios screen display. Failing to detect some monitors or hdmi cables.
There's a pretty standard way to get BKHD boards to unlock the advanced bios. If you search the forum you should find it described. I can't recall it at the moment.
The Chinese boards can be weird about bios screen display. Failing to detect some monitors or hdmi cables.
There's a pretty standard way to get BKHD boards to unlock the advanced bios. If you search the forum you should find it described. I can't recall it at the moment.
The chips that are hot is the power supply I think. 
I found the trick here https://forums.servethehome.com/ind...ies-nas-motherboard-topton-cwwk.42432/page-53 :
I found the trick here https://forums.servethehome.com/ind...ies-nas-motherboard-topton-cwwk.42432/page-53 :
I've reduce memory speed from 4800 to 4400 and
seems stable now! I will investigate to validate the stability. Thanks for you help and to this awesome forum!
Looking for advice on a persistent NVMe failure issue I've been chasing for over a month. Three different drives have exhibited the same failure
pattern, so I'm confident it's the board/slot, not the drives.
Hardware:
The NVMe is a x4-capable drive running in a x1 slot. There is no x4 M.2 slot on this board.
The problem:
The NVMe controller dies every ~12 hours with CSTS=0xffffffff, PCI_STATUS=0xffff followed by Unable to change power state from D3cold to D0. ZFS
pool suspends, requires reboot to recover. This has happened with all three drives (2x Samsung in a mirror pool and also attempted as a single drive, also now as 1x Crucial).
What I've tried as guided by Claude since I am new and learning this stuff
:
07:45:19 link=3013 (Gen3/8GT x1) pool=ONLINE d3cold=0 runtime=active
07:45:49 link=1011 (Gen1/2.5GT x1) pool=ONLINE d3cold=0 runtime=active
07:46:19 link=1011 (Gen1/2.5GT x1) pool=SUSPENDED d3cold=0 runtime=active
The link spontaneously retrained from Gen3 to Gen1, and 30 seconds later the controller died. All power management fixes were holding perfectly —
d3cold=0, runtime=active, power/control=on. The D3cold error in dmesg seems to be a consequence of the link failure, not the cause.
My current theory:
The x1 PCIe lane on this board seems to have marginal signal integrity at Gen3 (8GT/s). Something causes the link to retrain to the lowest speed, and the NVMe controller can't recover from this. I'm about to try forcing the link to Gen2 (5GT/s) via setpci to give more signal margin while still
providing ~500 MB/s.
Questions:
pattern, so I'm confident it's the board/slot, not the drives.
Hardware:
- Board: Generic Intel N100 NAS board (MW-N100-NAS branding, AMI BIOS 2.22.1287, DMI data all "Default string")
- CPU: Intel N100 (Alder Lake-N)
- RAM: 32GB DDR5
- Case: JONSBO N2
- NVMe: Crucial CT1000P5SSD8 1TB Gen3 (firmware P4CR324) — previously 2x Samsung 990 EVO Plus 2TB which both failed with the same symptoms
- HDDs: 5x 4TB in ZFS RAIDZ2
- OS: Proxmox VE 9.1.5, kernel 6.17.9-1-pve
| Root Port | Width | Speed | Device |
| 00:1c.0 | x1 | 8GT/s | NVMe (Crucial P5) ← the problem slot |
| 00:1c.3 | x1 | 5GT/s | Intel I226-V 2.5GbE |
| 00:1c.6 | x1 | 5GT/s | Intel I226-V 2.5GbE |
| 00:1d.0 | x2 | 8GT/s | Aquantia AQC113C 10GbE |
00:1d.2 | x1 | 8GT/s | JMicron SATA controller |
The NVMe is a x4-capable drive running in a x1 slot. There is no x4 M.2 slot on this board.
The problem:
The NVMe controller dies every ~12 hours with CSTS=0xffffffff, PCI_STATUS=0xffff followed by Unable to change power state from D3cold to D0. ZFS
pool suspends, requires reboot to recover. This has happened with all three drives (2x Samsung in a mirror pool and also attempted as a single drive, also now as 1x Crucial).
What I've tried as guided by Claude since I am new and learning this stuff
:- Kernel params: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off processor.max_cstate=1 intel_idle.max_cstate=1
- BIOS: ASPM disabled on all root ports, L1 substates disabled, clock/power gating disabled, CPU C6DRAM disabled, SATA aggressive LPM disabled, DMI link ASPM disabled
- Systemd service at boot: d3cold_allowed=0 on the NVMe device, all PCIe root ports, and critical PCH devices
- Udev rule disabling d3cold on all PCIe bridges by device class power/control=on forced on NVMe and its root port
- Removed broken Thunderbolt controller (00:0d.0, stuck in D3cold error at every boot) from PCIe bus at boot
- NVMe keepalive timer (4KB read every 2 minutes)
07:45:19 link=3013 (Gen3/8GT x1) pool=ONLINE d3cold=0 runtime=active
07:45:49 link=1011 (Gen1/2.5GT x1) pool=ONLINE d3cold=0 runtime=active
07:46:19 link=1011 (Gen1/2.5GT x1) pool=SUSPENDED d3cold=0 runtime=active
The link spontaneously retrained from Gen3 to Gen1, and 30 seconds later the controller died. All power management fixes were holding perfectly —
d3cold=0, runtime=active, power/control=on. The D3cold error in dmesg seems to be a consequence of the link failure, not the cause.
My current theory:
The x1 PCIe lane on this board seems to have marginal signal integrity at Gen3 (8GT/s). Something causes the link to retrain to the lowest speed, and the NVMe controller can't recover from this. I'm about to try forcing the link to Gen2 (5GT/s) via setpci to give more signal margin while still
providing ~500 MB/s.
Questions:
- Has anyone seen similar link retraining issues on these Aliexpress Intel N100 NAS boards?
- Is forcing Gen2 via setpci on the root port a reliable long-term fix, or just a bandaid?
- Any other ideas for what could cause periodic link retraining on a x1 lane? The ~12h interval doesn't correlate with temperature — we've monitored thermals and they're stable before failures.
- Is a new motherboard just going to be the best next solution?