Jump to content
XPEnology Community

How to have DS3622xs recognize nvme SSD cache drive (Maybe works on other models).


Recommended Posts

Posted
3 minutes ago, Peter Suh said:

What type of media did you record the img file to?
A USB stick?
Do you have any additional external storage on your GEN10?

yes... USB stick... no other external... 2 x internal SATA HDD, 2 x EVO970 plus on startech (PEX8M2E2) PCIE NVME card 

Posted (edited)
17 minutes ago, Mikael Juber said:

yes... USB stick... no other external... 2 x internal SATA HDD, 2 x EVO970 plus on startech (PEX8M2E2) PCIE NVME card 

 

Which image from this list did you use?
Is it the first mshell.img?
And is your BIOS using Legacy (CSM) or UEFI boot?

 

2025-01-077_36_23.thumb.png.19398ab6a284a3aa1d3c07a42de6d0d0.png

Edited by Peter Suh
Posted

@Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick,  but the nvme still not show on storage manager

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

already edit to

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

but when reboot it come back again to original...

any option...?
 

Posted
1 minute ago, Mikael Juber said:

@Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick,  but the nvme still not show on storage manager

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

already edit to

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

but when reboot it come back again to original...

any option...?
 

 

The Synology model you are using now is DS3622xs+, right?
I will come back after looking into how the program handles /etc.defaults/extensionPorts and how to find out the exact PCI address.
I haven't used it for a long time, so my memory is hazy.

Posted
8 minutes ago, Mikael Juber said:

@Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick,  but the nvme still not show on storage manager

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

already edit to

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

but when reboot it come back again to original...

any option...?
 

 

/etc.defaults/synoinfo.conf
Find the two items below and change them like this.
supportnvme="yes"
support_m2_pool="yes"

Posted
21 minutes ago, Mikael Juber said:

@Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick,  but the nvme still not show on storage manager

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

already edit to

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

but when reboot it come back again to original...

any option...?
 

 

Verify the address value once more with the results of the command below.


ls -d /sys/block/nvme*
/sys/block/nvme0n1   /sys/block/nvme0n2

 

cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4
cat /sys/block/nvme0n2/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4

Posted (edited)
25 minutes ago, Mikael Juber said:

@Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick,  but the nvme still not show on storage manager

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

already edit to

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

but when reboot it come back again to original...

any option...?
 

 


As long as the disks addon is used, it will just keep reverting to the wrong values on every reboot.
https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/disks/releases/install.sh#L384

 

Let me think about the method.
Please answer my question first.

Edited by Peter Suh
Posted (edited)

@Mikael Juber

 

As of now, there seems to be a bug in the way disks addon handles /etc.defaults/extensionPorts.

 

I think it would be better to change the Synology model to another one and migrate.
These are completely different models that recognize the NVMe Cache.


I recommend changing to the DS1621xs+, which is a Broadwellnk platform similar to the DS3622xs+.

 

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/disks/releases/install.sh#L460C50-L460C59

Edited by Peter Suh
Posted
1 hour ago, Peter Suh said:

Which image from this list did you use?
Is it the first mshell.img?
And is your BIOS using Legacy (CSM) or UEFI boot?

 

2025-01-077_36_23.thumb.png.19398ab6a284a3aa1d3c07a42de6d0d0.png

using the first shell.img and UEFI boot

Posted
1 hour ago, Peter Suh said:

/etc.defaults/synoinfo.conf
Find the two items below and change them like this.
supportnvme="yes"
support_m2_pool="yes"

yes... already like that... no need to change it

 

1 hour ago, Peter Suh said:

Verify the address value once more with the results of the command below.


ls -d /sys/block/nvme*
/sys/block/nvme0n1   /sys/block/nvme0n2

V1902@Synology:/$ ls -d /sys/block/nvme*
/sys/block/nvme0n1  /sys/block/nvme1n1
 

i think it verified...

 

 

Posted (edited)
1 hour ago, Peter Suh said:

cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4
cat /sys/block/nvme0n2/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4

this 2 command not show anything

 

V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4
-sh: grap: command not found
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
cat: /sys/block/nvme0n2/uevent: No such file or directory
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ ls -d /sys/block/nvme*
/sys/block/nvme0n1  /sys/block/nvme1n1
V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

Edited by Mikael Juber
Posted (edited)

on the setup i think the Loader get the address correctly...

already migrate to DS1621xs+... but still no luck showing the NVME drive on Storage Manager

 

WhatsApp Image 2025-01-08 at 21.55.34_3e518271.jpg

Edited by Mikael Juber
Posted (edited)
1 hour ago, Mikael Juber said:

this 2 command not show anything

 

V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4
-sh: grap: command not found
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
cat: /sys/block/nvme0n2/uevent: No such file or directory
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ ls -d /sys/block/nvme*
/sys/block/nvme0n1  /sys/block/nvme1n1
V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

 

2025-01-0912_18_28.thumb.png.ef2e66b814e451010e71afe916302243.png

 

 

A peculiarity of this card is that the disk add-on for REDPILL cannot find the PHYDEVPATH in /sys/block/nvme0n1/uevent.

 

You can see what addons are there with the following command:
cat /sys/block/nvme0n1/uevent

 

Currently, all kinds of loaders ARC/RR/MSHELL use this disks as a common mandatory addon,

so there is currently no way to exclude it and do the manual configuration you want.

 

https://github.com/AuxXxilium/arc-addons/blob/main/disks/install.sh#L424

 

2025-01-0912_52_59.thumb.png.09ac38ea3cf91c45f4fbba8682839bf9.png


I will provide a script that can remove the disks addon from mshell.
I think you should go back to DS3622xs+ and keep the settings you mentioned above.

Edited by Peter Suh
Posted

@Mikael Juber

 

If you see the loader build menu of mshell,
log in with a separate ssh utility as tc/P@ssw0rd account and try the command below.

After using this command, you need to rebuild the loader.
After building the loader, disks should disappear from addons like this.

 

When rebuilding, be sure to re-execute the menu with the ./menu.sh command in the SSH utility.
You should never use the menu that appears in the xterminal.


 

sed -i "3485s/^/# /" /home/tc/functions.sh

sed -i '3513s/.*/ echo/' /home/tc/functions.sh

jsonfile=$(jq 'del(.disks)' /home/tc/redpill-load/bundled-exts.json) && echo $jsonfile | jq . > /home/tc/redpill-load/bundled-exts.json

 

2025-01-0912_39_58.png.a50df9719793a476326e942749f9d1d2.png

 

 

2025-01-0912_45_12.png.9646c364ef28ba98389591d9e678a32a.png

Posted
49 minutes ago, Peter Suh said:

You can see what addons are there with the following command:
cat /sys/block/nvme0n1/uevent

V1902@Synology:/$ cat /sys/block/nvme0n1/uevent
MAJOR=259
MINOR=3
DEVNAME=nvme0n1
DEVTYPE=disk
PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=nvme
V1902@Synology:/$ cat /sys/block/nvme1n1/uevent
MAJOR=259
MINOR=0
DEVNAME=nvme1n1
DEVTYPE=disk
PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:08.0/0000:0b:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=nvme
 

 

26 minutes ago, Peter Suh said:
sed -i "3485s/^/# /" /home/tc/functions.sh

sed -i '3513s/.*/ echo/' /home/tc/functions.sh

jsonfile=$(jq 'del(.disks)' /home/tc/redpill-load/bundled-exts.json) && echo $jsonfile | jq . > /home/tc/redpill-load/bundled-exts.json

will try...

Posted
1 hour ago, Mikael Juber said:

this 2 command not show anything

 

V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4
-sh: grap: command not found
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
cat: /sys/block/nvme0n2/uevent: No such file or directory
V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4
V1902@Synology:/$ ls -d /sys/block/nvme*
/sys/block/nvme0n1  /sys/block/nvme1n1
V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:00:01.0"
pci2="0000:00:01.0"
 

 

There is a typo.
It is PHYSDEVPATH not PHYDEVPATH.
S is missing.
Anyway, it seems like the result is getting the wrong BUS ID value (0000:00:01.0).

 

cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4

0000:00:01.0

 

cat /sys/block/nvme1n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4
0000:00:01.0

Posted (edited)

@Mikael Juber

 

I think the part where the PCI BUS ID is taken from the disks addon needs to be improved, so I'm currently redesigning the fix.


The last value in the device pass seems to be the PCI BUS ID, but the problem seems to be that the value right before it (the 4th field) is being taken by fixing it.


I'm currently conducting my own test with my NVMe device.


It has to do with the depth of the device pass. Usually, it's reported up to 3 depths, but in your case, it should be used up to 5 depths.

 

PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0

PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0

 

If the same phenomenon as yours doesn't occur with my device, can I request a test?

Edited by Peter Suh
Posted
2 hours ago, Peter Suh said:

@Mikael Juber

 

I think the part where the PCI BUS ID is taken from the disks addon needs to be improved, so I'm currently redesigning the fix.


The last value in the device pass seems to be the PCI BUS ID, but the problem seems to be that the value right before it (the 4th field) is being taken by fixing it.


I'm currently conducting my own test with my NVMe device.


It has to do with the depth of the device pass. Usually, it's reported up to 3 depths, but in your case, it should be used up to 5 depths.

 

PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0

PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0

 

If the same phenomenon as yours doesn't occur with my device, can I request a test?

 

 

This is the intermediate result of the test.
You can use both of the last BUS IDs for the PCI BUS ID.
They are both recognized as unique values, so there seems to be no problem.
My case is as follows, and your case will probably be like this.

 

0000:00:15.0 or 0000:03:00.0

PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0

 

0000:08:00.0 or 0000:09:00.0

PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0

 

However, I plan to use the output of the command below in my script to get the actual PCI BUS ID that Linux is pointing to:

lspci -d ::108

 

Posted

@Mikael Juber

 

I have fixed the bug in disks addon and completed the redistribution.
I tested it by mounting 3 nvme in vmware as follows.
All 3 are recognized normally.

 

https://github.com/PeterSuh-Q3/tcrp-addons/commit/0349887101cdd667e469326bbf5ac89321642309

 

# cat /etc.defaults/extensionPorts
[pci]
pci1="0000:03:00.0"
pci2="0000:0b:00.0"
pci3="0000:13:00.0"

# lspci -d ::108
0000:03:00.0 Class 0108: Device 15ad:07f0
0000:0b:00.0 Class 0108: Device 15ad:07f0
0000:13:00.0 Class 0108: Device 15ad:07f0

 

 

Your case should be within the normal operating range now.
Please stop using the script that excludes disks addon that I told you about yesterday
and try using the modified disks.

 

The command below is a script that restores the state worked on with 3 commands yesterday.

 

curl -kLO https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/functions.sh

 

Posted

@Peter Suh just got back from work... I don't got to do anything from last time you told me... So i don't need to run script... Since you already fix this bug, so what can must do now...? Download latest image and do the loader build again...?

Posted
54 minutes ago, Mikael Juber said:

@Peter Suh just got back from work... I don't got to do anything from last time you told me... So i don't need to run script... Since you already fix this bug, so what can must do now...? Download latest image and do the loader build again...?

 

 

The latest image will be updated automatically the moment menu.sh is executed.


With this update, just rebuild the loader and check if the disks addon is visible again like I captured yesterday.


Now, as I expected, you should see the cache.

 

Please share your results.

 

Your case is special.

Posted (edited)

@Peter Suh i re-build the loader, and the address now correct

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"
V1902@Synology:/$

 

sh-4.4# cat /sys/block/nvme0n1/uevent
MAJOR=259
MINOR=0
DEVNAME=nvme0n1
DEVTYPE=disk
PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=nvme
sh-4.4# cat /sys/block/nvme1n1/uevent
MAJOR=259
MINOR=4
DEVNAME=nvme1n1
DEVTYPE=disk
PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:08.0/0000:0b:00.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=nvme
 

 

image.thumb.png.369b885e01a87c8edf251d630ab968ef.png

but still no nvme on storage manager... getting intresting...

Edited by Mikael Juber
Posted (edited)

supportnvme="yes"
support_m2_pool="yes"
 this already like that on synoinfo.conf

 

re-build to DS1621xs+

image.thumb.png.ddb01653355ade6d6f00a39681886237.png

or the PCIe card not recognize...? 

Edited by Mikael Juber
Posted (edited)
21 minutes ago, Mikael Juber said:

supportnvme="yes"
support_m2_pool="yes"
 this already like that on synoinfo.conf

 

re-build to DS1621xs+

image.thumb.png.ddb01653355ade6d6f00a39681886237.png

or the PCIe card not recognize...? 

 

 

V1902@Synology:/$ cat /etc.defaults/extensionPorts
[pci]
pci1="0000:09:00.0"
pci2="0000:0b:00.0"

 

Are these values checked from the beginning without any separate editing?

 

And this time you should go back to DS3622xs+.
If you don't see DS3622xs+ either
Please try DVA3221 too.

 

I will check the issue with DS1621xs+ separately.

Edited by Peter Suh

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...