[Proxmox: HBA passthrough & second virtual controller not detected]

On 5/30/2021 at 1:04 PM, Guest said:

It works!

I think I finally understood how this whole thing comes together and achieved exactly the configuration I wanted:

 

 

No synoinfo.conf modification is needed here. For this to work I had to set the boot config to include:

DiskIdxMap=0C0005 SataPortMap=157

 

 

 

But HOW did I get these values

What didn't make sense to me was how "maxdisks" (in synoinfo.conf, patched to 12 by Jun's loader), "SataPortMap", and "DiskIdxMap" play together. Often times posts just list these values as correct ones without explanation. The kconfig is often shown as an explanation (https://github.com/cake654326/xpenology/blob/master/synoconfigs/Kconfig.devices). While it does explain things it has a significant typo in DiskIdxMap and doesn't take Xpenology synoboot hacking into consideration. However it is actually pretty simple:

• maxdisks tells DSM how many disks the UI should enumerate and show in Storage Manager, it seems to have nothing to do with disk detection by the OS. That's why most configs just default to 12 as having this number higher than the actual number of slots will not cause problems.
• SataPortMap is a list of digits (one character = one entry) which are read in order to tell DSM how many ports per controller to initialize (max 9; in my example 1 port at 1st controller, 5 ports at 2nd, and 7 at 3rd)
• DiskIdxMap is a list of hex pairs (two characters = one entry) which instructs DSM how to map numbered ports from controllers to sda-sdz devs. The order of values here is the same as in SataPortMap. In my example above it maps like so:
  • 0C (dec: 12)
    • 1st controller starts mapping from 13th position
    • 1st controller had 1 port in SataPortMap
    • Result: [sdm]
  • 00 (dec: 0)
    • 2nd controller starts mapping from 1st position
    • 2nd controller had 5 ports in SataPortMap
    • Result: [sda] [sdb] [sdc] [sdd] [sde]
  • 05 (dec: 5)
    • 3rd controller starts mapping from 6th position
    • 3rd controller had 7 ports in SataPortMap
    • Result: [sdf] [sdg] [sdh] [sdi] [sdj] [sdk] [sdl]

With such configuration as above (and on the screenshot) the system sees a direct mapping between bays (even if empty) and sdX:

# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors

(sda and sde are missing as the ports 1 and 5 of the PCI controller aren't connected; sdf is the 1st port of the QEMU controller)

 

sdm is missing from the list as it is "renamed" to synoboot:

# fdisk -l /dev/synoboot | grep 'Disk /'
Disk /dev/synoboot: 50 MiB, 52428800 bytes, 102400 sectors

 

 

But I said I have two controllers... or do I?

An important missing bit which doesn't seem to be explained fully anywhere is that the first controller is (always?) the one where DSM boots from. Since USB devices are also SCSI-based (like SATA):

[    5.500034] sd 13:0:0:0: [synoboot] Attached SCSI removable disk

This means they will appear as sdX too. This is exactly why DiskIdxMap maps the first controller to start from 13th and why SataPortMap should list a single port in the first controller. In such configuration kernel will always put the boot device (residing on the 1st controller) outside of the 12 maxdisks making it invisible in the UI. Then the 2nd controller (which in my case is the PCI controller) starts normally from sda, making the UI numbering sane (starting from "Disk 1"):

This can be easily confirmed by setting SataPortMap to 057 - it will instantly cause a nice KP 

 

 

 

What about eSATA & synoinfo.conf?

On top of these above "internalportcfg" / "esataportcfg" / "usbportcfg" masks are used to decide which of the sda-sdz devices are treated as internal / eSATA / USB. When something is connected to the DSM. With settings above the defaults for DS3615xs make perfect sense:

• internalportcfg=0xfff -> first 12 devices (sda-sdl) should be treated as internal

• esataportcfg=0xff000 -> devices 13-20 (sdm-sdt) should be treated as eSATA

• usbportcfg=0x300000 -> devices 21-22 (sdu-sdv) should be treated as USB

The DS3615xs according to the data sheet has 12 bays and 2 USB ports.

 

Any unmapped devices or controllers will be attached with letters after the mapped boundary. So connecting a USB stick in my configuration results in sdu:

# fdisk -l /dev/sd? | grep 'Disk /'
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk /dev/sdf: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disk /dev/sdu: 14.6 GiB, 15682240512 bytes, 30629376 sectors

 

...and a correctly mapped entry in the UI:

 

thank you. such a good explanation on how to map SATA device.

[RedPill - the new loader for 6.2.4 - Discussion]

thank you @ThorGroup. really appreciated the effort.

 

22 hours ago, ThorGroup said:

1. I'm not a developer, can I help?
   At this stage most likely not. However, we wish to have some testing version not too far in time. For various reasons we cannot (and not willing to) accept any donations. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :)))

 

then I will wait for the proper stage later on, for testing etc.

 

22 hours ago, ThorGroup said:

1.  
2. ... we can say two things: Jun's loader doesn't seem to do any evil things, and the actions any loader needs to perform in the system after the initial load are minimal (e.g. fake responses to "turn on HDD led")...

 

after using the code for a while now, I also can testify for this statements.

[Tutorial: DSM 6.x on Proxmox]

On 6/13/2017 at 12:42 PM, lemon55 said:

In fact, everything is much simpler!

1. Create HDD, I did SATA0, RAW format (because synology.img is a RAW disk)

2. Replace the resulting disk**1**.raw file with synology.img (where it lies) with renaming.

3. In the UI, we remove the disk (once!). It will become disabled. Then click on it two times - connect sata0, raw. It will be displayed as 50mb.

4. Profit!!!

Only e1000, this has already been discussed - Virtio does not work!

 

thank you, @lemon55. i just got my xpenology online on Proxmox 7.0. somehow I cannot mount synoboot.img using the @fonix232 usb method. it seems does not work on Proxmox 7.0. maybe there are different arguments for proxmox 7.0.

 

if there any other member that can mount using usb method on Proxmox 7.0, do share.

 

**************************

Proxmox Version: 7.0-8
Jun's Loader version: v1.03b DS3615xs
DSM: DS3615xs 6.2.3-25426 Update 3
****************************

[Virus/Trojan - 4.3 Update your Xpenology now]

thanks for all the hardwork.

[Improving network speed on Synology NAS]

hi. long time lurker.

I'm still reading throughout this forum learning to setup my server properly.

 

First thing first, I would like to test connections and performance for my server. I tried to run iperf to do this. already loaded in Ubuntu with iperf package. but as I go through the help, it sound like iperf need to be run on each node of testing. (PC and server).

 

How to install and run iperf in my server?

I have not run into any log in this forum regarding iperf except this thread.

 

my setup :

N54L

DSM 4.2-3211

8GB RAM ECC