IG-88

i had a (cheap) jmb585 m.2 and it never worked stable, i also had concerns about flimsy pcb (might crack or parts get damaged when pressing to hard like inserting cables when already mounted in m.2, also the force 5 or 6 sata cables to that flimsy thin board can be a problem, that needs some adjustment too to not run into problems when working inside the system after placing the m.2 adapter), had more success with m.2 cable based adapter that terminated in a pcie 4x slot but also there was no universal solution as one with a slightly longer cable did not work stable with one specific controller, i ended up only using this m.2 contraptions for 10G nic) or not at all) and did spread the needed sata ports over the pcie 4x and 1x slots of the m-atx board i use (pcie 1x slot with jmb582) - a few bugs more for the controllers is better then a shredded btrfs volume (that is often hopeless beyond repair in a situation like this - learned that the hard way, but i also do backups of my nas ...) most normal housings cant have more then 12-14 3.5" hdd's and that often can be achieved with a m-atx or atx board and more ahci adapters for small money (like 6 x onboard, 5-6 sata by one jmb585 or asm1166 in a 4x slot and one or two 2port adapters in 1x slots - the 16x slot or one 4x slot might already be used for a 10G nic in my scenarios, if a 16x and and a 4x slot is free then two 2x/4x cards can add 10-12 sata disks to the 6 sata onboard ...)

i use arpl with a dva1622 and 6 disks (original has 2) and arc with 3622 and 13 disks (original 12), no problems, in the graphics you see a box with the original amount of slots but in using there is just the "normal" and old 26 disk limit, you will see all disks in HDD/SSD listing of disks you might want to change from 918+ to something newer as 918+ might loose its support and might not get updates as long as newer models (the guarantee is about 5 years, anything above that depends) depending on the features you need (like intel quick sync video) there might be some limits of models you can choose in the loader there is also a model specific cpu thread limit in the kernel but as you use a low spec cpu for you new system that wont be much of a problem, only thing with new er intel cpu's might be that the old 4.x kernel in its original form does not support 12th gen intel qsv and it depends on the loader how far that support is working as it needs extra drivers from the loader, so you might need to read up on that in the loaders doku or here in the forum (i use a older intel cpu with the dva1622 that is working with syno's original i915 driver so i'm not that much up to knowing whats the best solution now, dva1622 comes with a nice feature set ootb when the i915 supports the cpu but there was also some interesting stuff going on with sa6400 and its 5.0 kernel with i915 extended drives, initially here https://github.com/jim3ma but i guess some of it might have found its way to other loaders by now) in genral it does nor matter if the original unit has a amd or intel cpu for just the basic NAS stuff, only when using KVM based VMM from synology or specific things like intel qsv it becomes important (as kernels per from synology are tailored for cpu's to some degree and the most obvious is the thread limit) i'd suggest to use a different usb thumb drive and a single empty disk (maybe two to connect to the last sata port to see how far it gets) to do some tests (you can keep the original usb and he disks you use now offline (just disconnect the disks), play with the loaders model until you find your sweet spot and then use that configured loader to upgrade to the new model and dsm version (7.1 is still fine and as its a LTS version it will get updates at least as long as 7.2)m when creating a system from scratch with empty disks the partitions layout for system and swap will be different with 7.1/7.2 but upgrading from 6.2 and keeping the older smaller partitions is supported by synology so there is no real need to start from scatch for 7.x https://kb.synology.com/en-global/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have

you just forgot about the fun we had as its quiet some time since you updated your 6.2.3 6.2.2 with its different pcie kernel options or 6.2.3-25xxx (and all after that up to 6.2.4) just to name a few arc-a and arc-c are about a fixed dsm type like RS4021xs+ and SA6400, more automated and arc-c even has a custom kernel option to have more cpu cores usable (also its the one dsm x64 version that has kernel 5.x) just try the normal arc (and read about the limitations and special things of models in his wiki, https://github.com/AuxXxilium/AuxXxilium/wiki/Arc:-Choose-a-Model-|-Platform) but if you want to use 6.2. and jun's laoder just try it. disks should be no problem with ahci controllers, if the last extra gets you nic working then it should be fine you should never expose such old unpatched system directly to the internet as 6.2.3 has a lot of security fixes missing by now

https://github.com/AuxXxilium/AuxXxilium/wiki https://auxxxilium.tech/redpill/ and he also has a lot of stuff on youtube https://www.youtube.com/@AuxXxiliumTech

in the 1st post of this thread are links, also for 918+ and one of the links is still working as it has i219 (intel e1000e driver) and i211 (intel igb driver) at least one should work (if you really want to torture yourself with that old 6.2.3 stuff) asm1166 and jmb585 are both ahci compatible and will work even without anx eytra drivers as the ahci support is a fixed part in synologys kernel (that is always used with jun's or newer loaders) i'd suggest using a newer loader like arc, support dsm 7.1 (lts) oder 7.2, plenty of drivers and loads of fixes to special conditions arc gets a lot of effort and is well maintained https://github.com/AuxXxilium/AuxXxilium/wiki

arc loaders wiki can also be a good source of information https://github.com/AuxXxilium/AuxXxilium/wiki (the important and limitations part from the start page) https://github.com/AuxXxilium/AuxXxilium/wiki/Arc:-Notice-&-Workarounds https://github.com/AuxXxilium/AuxXxilium/wiki/Arc:-SataPortMap-&-SataRemap

if the module is not loaded it can't detect the press of the power button the loader should (at least when activating the acpid add on) load that module in theory a insmod /lib/modules/button.ko should fix that and after that the shutdown might work as expected if you found soemthing thats working for you that i guess its a solved problem

check what mdadm has to say about that cat /proc/mdadm at least there should be something if disks from a raid are missing my (untested) assumption was that these things might not work on DT models they might use different things now like changes in device tree? maybe changes to a non DT model for your install or as suggested earlier change to jmb585/582 cards to get the port count you are aiming for you can try to dive deep into DT, syno's kernel (kernel source is available), the mods they have done and the shiming in the loader ... the less time consuming and non developer way is just to circumvent problems and using asm1166 only as last controller in the system is that way (or not using it at all or if you did not already have bough disks just lower the needed port count with bigger disks (i reduced my system from 12 to 5 disks that way) that might have been the way with jun's loader but the new loader (rp) works different, you would need to edit a config file of the loader for that, the loader now has its own boot and menu system to do that and re-writes the config file when saving the loader config (if you change the resulting config file manually you changes might get lost when re-running loader config later (like having DT and needing to renew the device tree after changing hardware)

evdev might be now part of synos kernel with 7.x (like ahci) you can check on button.ko with cat /proc/modules | grep button that should show if its loaded

check if evdev.ko and button.ko are present and loaded

sata_remap=9>0:0>9 https://xpenology.com/forum/topic/32867-sata-and-sas-config-commands-in-grubcfg-and-what-they-do/ https://gugucomputing.wordpress.com/2018/11/11/experiment-on-sata_args-in-grub-cfg/ did you see this`? https://xpenology.com/forum/topic/52094-how-to-config-sataportmap-sata_remap-and-diskidxmap/ also a possible solution might be to just use one asm1166 and place it as last card, that way the 32 ports are no problem like 6 x sata onbard, 5 x sata with jmb585, 6 x sata with asm1166 if needed another jmb585 or jmb582 card can be placed in the middle to keep asm1166 last, jmb582 will be a pcie1x card but sometime all the good slots are all used but even a 1x slot can be useful (afair there a re even jmb585 with pcie 1x but using to many of the ports might result in some performance degradation) there is also a newer firmware from 11/2022 for asm1166 (at least newer the the one from silverstone) but it does not fix the 32 port problem https://winraid.level1techs.com/t/latest-firmware-for-asm1064-1166-sata-controllers/98543/18

looks like it when reading here https://www.servethehome.com/hpe-proliant-microserver-gen10-plus-ultimate-customization-guide/2/ "... hi again, I can confirm i5-9400 works, didn’t try i5-9400f ... I can confirm the i7-9700f works. ..."

vieleicht hilft ja ein video "How to install QNAP NAS on VMWare in pc." https://www.youtube.com/watch?v=VCElcA6CdBI es gab in einem qnap.zip mit beiden images (img/vmdk) auch mal eine pdf anleitung wie man die benutzen kann ist zwar von 2020 aber vieleicht hilft es dir, hänge ich hier mal mit an Anleitung-DE.7z

my old documentation about the mod is this (mvsas kernel 3.10.105 patch backport) diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c index 7b7381d..83fa5f8 100644 --- a/drivers/scsi/mvsas/mv_init.c +++ b/drivers/scsi/mvsas/mv_init.c @@ -729,6 +729,15 @@ static struct pci_device_id mvs_pci_table[] = { .class_mask = 0, .driver_data = chip_9485, }, + { + .vendor = PCI_VENDOR_ID_MARVELL_EXT, + .device = 0x9485, + .subvendor = PCI_ANY_ID, + .subdevice = 0x9485, + .class = 0, + .class_mask = 0, + .driver_data = chip_9485, + }, { PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */ { PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ { PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ ------------------------------------------------------------ delete new and old 9485 section and replace with the following (as from kernel 5.x) { PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 }, /* Marvell 9480/9485 (any vendor/model) */ i might need to have look at the old kernel source to figure out what it was about "delete new and old 9485 section", i will do this if needed (and there would also be the patched kernel in my old vm i was using to build the modules) there was also a old todo list having a point "new mvsas fix" but i cant remember what this was about i also have 2 patches for adding alx killer 2400 and 2500 to the old kernels edit: code in my mv_init.c from kernel 3.10 looks like this mv_init.c ... <------>{ PCI_VDEVICE(MARVELL, 0x6485), chip_6485 }, <------>{ PCI_VDEVICE(MARVELL, 0x9480), chip_9480 }, <------>{ PCI_VDEVICE(MARVELL, 0x9180), chip_9180 }, <------>{ PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1300), chip_1300 }, <------>{ PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1320), chip_1320 }, <------>{ PCI_VDEVICE(ADAPTEC2, 0x0450), chip_6440 }, <------>{ PCI_VDEVICE(TTI, 0x2710), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2720), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2721), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2722), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2740), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2744), chip_9480 }, <------>{ PCI_VDEVICE(TTI, 0x2760), chip_9480 }, <------>{ <------><------>.vendor><------>= PCI_VENDOR_ID_MARVELL_EXT, <------><------>.device><------>= 0x9480, <------><------>.subvendor<---->= PCI_ANY_ID, <------><------>.subdevice<---->= 0x9480, <------><------>.class<><------>= 0, <------><------>.class_mask<--->= 0, <------><------>.driver_data<-->= chip_9480, <------>}, <------>{ <------><------>.vendor><------>= PCI_VENDOR_ID_MARVELL_EXT, <------><------>.device><------>= 0x9445, <------><------>.subvendor<---->= PCI_ANY_ID, <------><------>.subdevice<---->= 0x9480, <------><------>.class<><------>= 0, <------><------>.class_mask<--->= 0, <------><------>.driver_data<-->= chip_9445, <------>}, <------>{ PCI_VDEVICE(MARVELL_EXT, 0x9485), chip_9485 }, /* Marvell 9480/9485 (any vendor/model) */ <------>{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */ <------>{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1041), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1042), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1043), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1044), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1080), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1083), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ PCI_VDEVICE(OCZ, 0x1084), chip_9485}, /* OCZ RevoDrive3/zDriveR4 (exact model unknown) */ <------>{ }<--->/* terminate list */ }; static struct pci_driver mvs_pci_driver = { <------>.name<-><------>= DRV_NAME, ...

YES you are right i did not read careful enough but the driver required is correct and arpl seems to to have that one, as arpl is unmaintained atm i'd suggest using ARC loader https://github.com/AuxXxilium/arc that one comes with a wider selection of drivers and to be sure i just checked for that driver and it is present there, so it should work with this loader