[Help] Subject: Dual Kingston KC3000 (Maxio MAP1602) NVMe detection issue on F4-425 Plus

RAID, Volume, storage pool, hard drive, USB, SSD cache and iSCSI LUN
Post Reply
User avatar
tsurkan4ik
Posts: 2
Joined: 06 Apr 2026, 20:50
Russia

[Help] Subject: Dual Kingston KC3000 (Maxio MAP1602) NVMe detection issue on F4-425 Plus

Post by tsurkan4ik »

Hi everyone.
I am experiencing a persistent issue where TOS fails to initialize two identical Kingston KC3000 SSDs (Maxio MAP1602 controller) simultaneously, although both are perfectly detected in the BIOS and visible as separate PCI devices (05:00.0 and 06:00.0) via lspci. In the OS, only one drive is assigned a node (either /dev/nvme0 or /dev/nvme1), and they seem to conflict or overwrite each other during the kernel's NVMe driver initialization. I have already tried disabling ASPM, Power Gating, and adjusting PCIe generations in the BIOS without success; the system refuses to mount both drives at the same time despite the hardware being recognized at the bus level.
thanks in advance.


Tsurkanu Denis
User avatar
EriChan
TM Support
Posts: 196
Joined: 06 Jan 2026, 12:27
United States of America

Re: [Help] Subject: Dual Kingston KC3000 (Maxio MAP1602) NVMe detection issue on F4-425 Plus

Post by EriChan »

Regarding feedback that the Kingston KC3000 SSD (with the Novatek Maxio MAP1602 controller) cannot be initialized simultaneously on TNAS devices, here are detailed explanations and troubleshooting steps:

Given that you have already attempted ASPM, power gating, and PCIe frequency adjustments at the BIOS level, and that lspci recognizes two physical devices (05:00.0 and 06:00.0), this indicates that both the physical layer and the PCIe topology are functioning normally. The issue likely lies in the Linux kernel NVMe driver loading and device node allocation phase.

According to relevant online information, certain batches of MAP1602 controller SSDs may have duplicate serial numbers (SN) or IEEE identifiers in their firmware. When the Linux kernel detects two NVMe devices with identical identifiers, it may, as a security measure, refuse to assign a `/dev/nvmeX` device node to the second device, or exhibit the “overwrite” phenomenon you described.

Troubleshooting:

Solution 1: Check for Device Identifier Conflicts
1. Use TOS Desktop > Terminal, or log in to your TNAS via SSH
2. Retrieve error messages

Code: Select all

 dmesg | grep nvme

This will display specific error messages from the kernel during the initialization of these two disks, such as duplicate ID or failed to set up queues.

3. Execute the following commands and compare the results:

Code: Select all

cat /sys/class/nvme/nvme0/serial
cat /sys/class/nvme/nvme1/serial  # If the second node appeared briefly

# Or view all disk IDs
ls -l /dev/disk/by-id/
If the serial values for both drives are exactly the same, the Linux kernel’s NVMe module will treat them as multipath instances of the same device, causing a conflict.


Solution 2: Cross-Verification

1. Single-Drive Test: Insert the two drives into slots 1 and 2, respectively, and verify that both drives can successfully create `/dev/nvme0` when operating in single-drive mode.

2. Mixed-drive test: If you have SSDs from other brands (such as Phison or Samsung), try a “KC3000 + other brand” combination. If this combination works normally, it is highly likely that the issue is caused by a MAP1602 controller identifier conflict.
Post Reply

Return to “Storage”