IG-88

you can try "journalctl" in the console (q for quit) files are in /var/log/ my test system (9th gen cpu with tested hardware) did not show unusual behavior but there is not much installed atm, 7 disks and some packages (and no internet access for the system -> synowedjat-exec[18930]: connection error while downloading payload. [35], synowedjat-exec[18930]: Error downloading payload, synowedjat-exec[18930]: Error execute payload, - no thanks not interested in that stuff atm) there are some log messages indicating some minor problems with the loader ... 2023-03-31T20:21:51+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_read.c:46 Read OOB reg 292 failed, ret=-1 2023-03-31T20:21:51+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_write.c:51 Write OOB reg 292 failed, ret=-1 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_tools.c:107 CMAC RESET error 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_read.c:46 Read OOB reg 292 failed, ret=-1 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_write.c:51 Write OOB reg 292 failed, ret=-1 2023-03-31T20:52:38+02:00 test3 kernel: [174006.217158] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T20:52:38+02:00 test3 kernel: [174006.228753] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed ... 2023-03-31T23:16:27+02:00 test3 kernel: [182634.562114] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.573636] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.585204] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.596803] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:17:18+02:00 test3 kernel: [182685.586770] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:18+02:00 test3 kernel: [182685.968973] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:18+02:00 test3 kernel: [182686.270364] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:19+02:00 test3 kernel: [182686.571662] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" ...

ich bin mir nicht sicher was du gemacht hast gruppenrichtlinien sind eigentlich etwas windows/domain spezifisches, und haben nicht wirklich etwas mit dem lokalen linux des DSM zu tun wo genau in der gui hast du was eingestellt? der arpl loader hat ein addon mit das über framebuffer eine lokale console auf dem dsm gertät ermöglicht (was es sonst nur regulär mir 0-modem kabel über seriellen port gab) ansonsten kann man auch ein rescue/recovery linux booten , das raid1 der system patitionen mounten und dort sachen zurücksetzen (wenn man genau weiß was man macht) hängt ein wenig davon ab wie viel man konfiguriert hat aber für ein reset der config auf wekrseinstellungen in dsm hat man eher im blick wie der aufwand ist, wenn man neuland betritt und sich erst mal einlesen und ausprobiren muss dann geht da schnell ein mehrfaches an zeit drauf als wenn man einfach zurücksetzt und neu einstellt, evtl. hat man ja auch ein backup der config und pakete so das man nach einem zurücksetzen wieder alles so bekommt wie man es hatte

ok, thats very recent then and its only for year 23 units and and 21/22 units for dsm 7.2 (and thats in beta riht now) i guess if its supported in some units it might be possible to make it on others available too, so just wait for it or look here https://xpenology.com/forum/topic/67961-use-nvmem2-hard-drives-as-storage-pools-in-synology/ sound like one more reason to test and looking forward to have it on the main unit, for now i'm just testing it (but as dva1622 screwed my installation (just dsm config and packages, data are ok) i might switch soon to sa6400 too

hard to say as the loader does shiming to translate drives from the hardware driver to dsm, it might give you no advantage over using a "normal" sas backplane / unit for more drives dsm usually checks about original stuff and its firmware and will handle it differently but with the loaders interference it might not work the same way as on a original hardware

that the dsm default, m.2 nvme is only usable as cache, data volume will be some kind of mangling and can easily break on update (like fallback to unconfigured cache drive) anything measurable or just how the gui feels like?

i've run into a problem with the recent version of the loader, on start the 1st partition is filled up with log's until no space is left and then dsm shuts down and if i check the loader the 50MB partition has no space left any options to disable the log duplication to the 1st partition? exit: i increase the size of the 1st partition and it now cant fill it up (it ends with 57MB on the former 50MB), but still the system shuts down the moment its ready (i can see it already in synology assistant) beside digging into the system partitions log i can use the log on usb edit2: that seems to be the part where it goes wrong and all is shut down "platform error"? might be anything wrong with the shimming and emulation? its 7.1.1 U4 and it was running fine for about 4 weeks, only thing to mention is that i took out the 2nd nic 2 day ago yesterday loaders 1st partition was broken (log file problem from above) and file system was damaged, i replaced it yesterday with a new one and, re-entered sn and mac's and did the option to recover a installed system from the advanced menu edit3: i set up a new usb flash drive from scratch, removed 2nd nic and it did not find my already installed system to uses its configuration, it did a complete new install, so all configuration incl. packages are gone (as i have a backup a will try a configuration restore later), data volume is still there (as it should be), it wanted to do a scrubbing not sure if i will stay with dva1622 after this, its also i little bit concerning to read this (how far will they go in "punish" mode?) https://xpenology.com/forum/topic/68080-synology-backdoor/ journalctl ... Mar 25 09:58:42 TheBox systemd[1]: Started SSDP service. Mar 25 09:58:42 TheBox synosystemctl[17042]: systemd_restart.cpp:24 synosystemd: [ssdp] try-restarted. Mar 25 09:58:42 TheBox synow3tool[17286]: Start Nginx Server in Normal Mode ...... Mar 25 09:58:42 TheBox systemd[1]: Reloaded Nginx. Mar 25 09:58:43 TheBox index.cgi[16670]: external/external_microp_id_check.c:56 Fail to open synobios Mar 25 09:58:43 TheBox root[17323]: platform error Mar 25 09:58:43 TheBox index.cgi[16670]: open synobios error, error=(6)No such device or address Mar 25 09:58:43 TheBox index.cgi[16670]: system_sys_init.c:81 synopoweroff: SYNOHWExternalControl[SYNO_SYS_SHUTDOWN] failed Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:110 FeasibilityCheck: [Info] Start feasibility check [poweroff] with type [critical]. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:129 FeasibilityCheck: [Info] [0] of feasibility check [poweroff] failed. Mar 25 09:58:43 TheBox index.cgi[16670]: system_poweroff_pre_hook.c:22 synopoweroff: Begin SYNOPowerOffPreHook action. Mar 25 09:58:43 TheBox index.cgi[16670]: plugin_action.c:317 synoplugin: [16670][PRE][poweroff][MAIN] Scripts=[CacheAdvisorPoweroffPlugin.sh,esynoscheduler-event-poweroff.sh]; Args=[POWEROFF_TYPE=poweroff] Mar 25 09:58:43 TheBox index.cgi[17333]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][CacheAdvisorPoweroffPlugin.sh][17333] ExitCode: 0 Mar 25 09:58:43 TheBox index.cgi[17333]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][CacheAdvisorPoweroffPlugin.sh][17333] Runtime: 0.007s Mar 25 09:58:43 TheBox index.cgi[17334]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][esynoscheduler-event-poweroff.sh][17334] ExitCode: 0 Mar 25 09:58:43 TheBox index.cgi[17334]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][esynoscheduler-event-poweroff.sh][17334] Runtime: 0.088s Mar 25 09:58:43 TheBox index.cgi[16670]: plugin_action.c:317 synoplugin: [16670][PRE][poweroff][MAIN] Runtime: 0.089s Mar 25 09:58:43 TheBox index.cgi[16670]: system_poweroff_pre_hook.c:27 synopoweroff: Finish SYNOPowerOffPreHook action. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:110 FeasibilityCheck: [Info] Start feasibility check [poweroff] with type [critical]. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:129 FeasibilityCheck: [Info] [0] of feasibility check [poweroff] failed. Mar 25 09:58:43 TheBox index.cgi[16670]: system_sys_init.c:133 synopoweroff: System is going to [poweroff] Mar 25 09:58:43 TheBox systemd[1]: Stopped syno-mkdhparam.service. Mar 25 09:58:43 TheBox systemd[1]: Stopping syno-mkdhparam.service... Mar 25 09:58:43 TheBox systemd[1]: Removed slice system-getty.slice. Mar 25 09:58:43 TheBox systemd[1]: Stopping system-getty.slice. Mar 25 09:58:43 TheBox systemd[1]: Removed slice system-serial\x2dgetty.slice. ...

i mitigated it for now by adding the following to the beginning of /etc/rc.network and /etc.defaults/rc.network rmmod pgdrv.ko rmmod r8168.ko insmod /usr/lib/modules/r8168.ko edit: doing it that way will not work after a update where as the rc.network might be replaced wit a new version and it will again not use the realtek nic

maybe not, as i could not find it in the loaders 3rd partition or /lib/modules/ on the installed system at least i could unload that one and r8168 and then just load r8168 and it look ok that driver seems related to firmware updates but where does it com from? not fix in syno's kernel so maybe rd.gz? yes its in syno's original rd.gz so removing it will be not possible i think, i guess rd.gz is protected in the same way as the kernel so removing it might not work found "initrd-dsm" on the 3rd partition of the loader and i think there we can see how its loaded the question then why its not unloaded with rmmod as it should be there is a oob.ROM in /.syno/patch/ (beside some other files (list see below) ... # # Update oob fw # OOB_FW_FILE="${Mnt}/oob.ROM" UpdateOobFw() { if [ 0 -ne $FsckFailed ]; then return 0 fi if [ "$SupportOobCtl" != "yes" ]; then return 0 fi if [ ! -f ${OOB_FW_FILE} ]; then return 0 fi /sbin/insmod /lib/modules/pgdrv.ko /usr/syno/sbin/syno_oob_fw_upgrade /parta ${OOB_FW_FILE} /verify if [ 0 -eq $? ]; then echo "Update OOB FW A success!" else echo "Update OOB FW A failed! Try FW B" sleep 5 /usr/syno/sbin/syno_oob_fw_upgrade /partb ${OOB_FW_FILE} /verify if [ 0 -eq $? ]; then echo "Update OOB FW B success!" sleep 5 # erase partA magic number, avoid boot into partA /usr/syno/sbin/syno_oob_fw_upgrade /er 64 else echo "Update OOB FW B failed! Skip update" fi fi /bin/rm -f ${OOB_FW_FILE} /sbin/rmmod pgdrv.ko } ... /.syno/patch/ DiskCompatibilityDB.tar GRUB_VER H2OFFT-Lx64 VERSION bios.ROM checksum.syno diskaction.tgz expired_models grub_cksum.syno model.dtb nvme oob.ROM platform.ini rd.gz smartctl synofwupgrade updater zImage

the sa6400 contains the new i915 modules, look in the 3rd partition of the loader and you will see i'm testing baremetal too, you should see something in /dev/dri just by booting into dsm your cpu is jasper lake and should work wit the new i915 driver

i have a 11th gen cpu notebook here to test the current state and can also have a 12th gen cpu notebook too (i5-1235u) for testing they dont have sata but with a m.2 to pcie cable adapter i can add a sata controller so its good for basic testing (as long as the intel onboard nic works with the loader) if you send me the kernel modules i can replace the files in the current sa6400 loader

no, that is elkhart lake, i dont thing that the gpu in that cpu is supported atm its up to 10th gen cpu for now or you will have to wait for the sa6400 to get "safe" an released in tcrp and arpl, sa6400 comes with kernel 5.10.x and in that would have way better i915 driver by default, sa6400 being a business oriented nas only unit without gpu support got a i915 driver added lately by adding the missing parts through backports (jim ma is doing this) imho more promising then 7.2 atm as 7.2 will not bring any kernel version changes so the one and only kernel 5.x unit is still be sa6400 (maybe some new 2023 release units might come with 5.x?), up to 11th gen is supported including jasper and elkhard lake, but as it is a "non dva" unit there might be problems using face recognition i survailance station but using videostations hardware transcoding and photos should work the same as on 920+ when looking for Ai and face recognition it might be "safer" to go with dva32xx units, getting the "right" nvidia gpu's for the driver involved in this units might be easier (but might be more expansive in purchasing and running as it will consume more power long term), the nvidia card in question are older now and might be easier to get 2nd hand - but it needs reading into this (driver version used be synology and its supported gpu's) easy gonig way is still fetching a 8th/9th gen cpu system and building around that dsm as we use it here is a appliance that can be complicated or impossible to have it your way so its often less hassle to bend yourself (hardware to use) in the way dsm needs, and that needs way more preparation and knowledge or asking around then most expect or want to and its often not the best way to buy the newest and best, most likely some "older" average hardware (from the gaming point of view) is better then anything new (synology is using highly customized old kernels and is slow taking it to the next level) i hope that gives you and other some ideas on how to go forward and also think about what you really need, specially with newer hardware and the need to just store date it might be easier to use open media vault (still my preferred fallback i keep up in case dsm breaks) or unraid - or think about buying a original units from synology, depending an the use case the "under powered" hardware is no problem and the hardware they sell is usually reliable and holds 5+ years (not flashy but solid) the only downside is that higher disk counts get really expansive but with 16TB HDD's or bigger a 4 slot unit might be ok (as long as at least a 2.5G nic is present)

jusst go into arpl's advaned section, there is a option to viev/edit the whole config file change netif_num: "3" mac1: b42e99743362 mac2: b42e99743363 mac3: b42e99743364 (choose whatver mac you like, usually you choose the mac's of the real nic's but it can take a 2nd try if you put i the onboard as 1st and find out after booting that you onboard got 3rd after the 2port nic the part in dsm is just the file /etc.defaults/synoinfo.conf ti change maxlanport to 4 maxlanport="4" and the reboot vim can be used as editor for that purpose, its kind of cryptic when 1st used but there are ton's of shot intros on how to use it it depends what you need, if its intel quick sync support then you cant use dva3221 as its ai stuff is nvidia only, no i915 driver

4.4.59+ is dsm 6.2 maybe you installed a package that copied the old driver, there is no information what dsm type you installed or what hardware you used and if it was a fresh install or a update nct6775 files in the loaders \modules\ directory are all ok check /lib/modules/udpates/ for old files that might need to be deleted you can also extract the right files manually from the loaders 3rd partition in modules are the tgz files for the platforms, depends on what you installed , 918+ would be apollolake

06:00.0 Class 0200: Device 10ec:8168 (rev 16) Subsystem: Device 1458:e000 Kernel driver in use: pgtool any idea why the pgtool (does not seem to be a loadable kernel module) is used instead of r8168? other odd thing was having 6 sata onboard + jmb585 (5 sata ports) and a asm1166 (6 sata but kernel finds 32 ports) together in the system at initial setup (only one disk at the 1st onboard port) resulted in a error at ~5% where the dsm could not format the disk - after stripping it down to onboard sata it worked edit: beside the peculiar format problem on install (i will check on that later, lots of controllers i can try to hit numbers >12 ports) there where no problems so far, 2 TB's copied so far and still going, i will also try to use mpt3sas and scsi_transport_sas with a lsi sas controller later (for now just 6 onbard + jmb585) sadly the sa6400 does not have the tn40xx.ko driver to support syno's own older tehuti 10G nics (3622 has this driver), had to pull a bnx2x 10G from another system to get 10G in the test system nvme ssd did work ootb, just plugin and go but as i had only one i did not left it in the system, read cache does not do much, maybe i will try a 4-6 sata ssd cache so stability is no problem so far on baremetal (i3-9100, 16GB RAM)

i had a closer look at the device id's in the i915 driver and its up to 11th cpu gen, ice lake (8Axx) tiger lake (9Axx) rocket lake (4Cxx) and Jasper Lake (4Exx) / Elkhart Lake (45xx) no 12th/13th gen alder lake or raptor lake (46xx)

G3930 is kaby lake aka 7th gen cpu, so if face recognition works it will also with a i3-7100 https://ark.intel.com/content/www/us/en/ark/products/97452/intel-celeron-processor-g3930-2m-cache-2-90-ghz.html

even after the firmware update my asm1166 still reports 32 sata ports, even with kernel 5.10 Mar 21 22:52:51 test3 kernel: ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled Mar 21 22:52:51 test3 kernel: ahci 0000:04:00.0: AHCI 0001.0301 32 slots 32 ports 6 Gbps 0xffffff3f impl SATA mode Mar 21 22:52:51 test3 kernel: ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst ... Mar 21 22:52:51 test3 kernel: ata12 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280100 irq 133 Mar 21 22:52:51 test3 kernel: ata13 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280180 irq 133 Mar 21 22:52:51 test3 kernel: ata14 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280200 irq 133 Mar 21 22:52:51 test3 kernel: ata15 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280280 irq 133 Mar 21 22:52:51 test3 kernel: ata16 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280300 irq 133 Mar 21 22:52:51 test3 kernel: ata17 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280380 irq 133 Mar 21 22:52:51 test3 kernel: ata18 : DUMMY Mar 21 22:52:51 test3 kernel: ata19 : DUMMY Mar 21 22:52:51 test3 kernel: ata20 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280500 irq 133 Mar 21 22:52:51 test3 kernel: ata21 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280580 irq 133 Mar 21 22:52:51 test3 kernel: ata22 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280600 irq 133 Mar 21 22:52:51 test3 kernel: ata23 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280680 irq 133 Mar 21 22:52:51 test3 kernel: ata24 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280700 irq 133 Mar 21 22:52:51 test3 kernel: ata25 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280780 irq 133 Mar 21 22:52:51 test3 kernel: ata26 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280800 irq 133 Mar 21 22:52:51 test3 kernel: ata27 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280880 irq 133 Mar 21 22:52:51 test3 kernel: ata28 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280900 irq 133 Mar 21 22:52:51 test3 kernel: ata29 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280980 irq 133 Mar 21 22:52:51 test3 kernel: ata30 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280a00 irq 133 Mar 21 22:52:51 test3 kernel: ata31 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280a80 irq 133 Mar 21 22:52:51 test3 kernel: ata32 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280b00 irq 133 Mar 21 22:52:51 test3 kernel: ata33 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280b80 irq 133 Mar 21 22:52:51 test3 kernel: ata34 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280c00 irq 133 Mar 21 22:52:51 test3 kernel: ata35 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280c80 irq 133 Mar 21 22:52:51 test3 kernel: ata36 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280d00 irq 133 Mar 21 22:52:51 test3 kernel: ata37 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280d80 irq 133 Mar 21 22:52:51 test3 kernel: ata38 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280e00 irq 133 Mar 21 22:52:51 test3 kernel: ata39 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280e80 irq 133 Mar 21 22:52:51 test3 kernel: ata40 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280f00 irq 133 Mar 21 22:52:51 test3 kernel: ata41 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7280f80 irq 133 Mar 21 22:52:51 test3 kernel: ata42 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7281000 irq 133 Mar 21 22:52:51 test3 kernel: ata43 : SATA max UDMA/133 abar m8192@0xf7280000 port 0xf7281080 irq 133 Mar 21 22:52:51 test3 kernel: ata19 : port disabled Mar 21 22:52:51 test3 kernel: ata18 : port disabled

not a stability issue but for some reason the onboard realtek nic (Gigabyte B365M HD3) did not work, after replacing it with a e1000e intel card it come up in network edit: devices in /dev/dri present on 9th gen cpu

one ssd only enables read cache and thats not much use in home environment, often more useful as data drive for docker/vm's or as faster temporary space (if there is any kind of faster network then 1G, with just 1G that the network will hold you back most of the time), also sata drives are limited to ~550MB/s by sata so even 2 disks as write cache are not that impressive as it will still hold back a 10G network so either a 3-4 sata ssd configration or two nvme ssd's would be some real improvement (if you trust the cache, it that does not work as intended you might end up with a file system beyond repair/recovery) raid1 over all drives in the system except cache drives, that raid1 (system partition and swap) is whats meant when you see a disk as initialized

beside a normal 9th gen hardware with up to 20 disks (some ssd's and 10G nic too, and maybe one m.2 nvme ssd) i could test i915 on newer notebooks with 11/12th gen cpu's (that needs a m.2 to pcie cable adapter for a ahci sata controller but i did that some time ago) anything special beside testing i915 transcoding and copy one or another TB? lsi sas? (9211-8i)

from that it does not seem to be dell bios, the chipset seems to lack ahci in general https://www.jagatreview.com/2011/03/intel-h61-chipset-review-almost-all-the-features-for-less/ could be fixed with a pcie based ahci capable controller (but even if you get 6.2 up and running its not safe to assume that shutdown will work) jmb585 or asm1166 in 16x slot or jmb582 in 1x slot might be a possible choice 3615 might be a interesting choice as its the only unit still having kernel 3.10 so there might be a difference arpl does have 3615 support, maybe took for a the choice to enable all units (beta or whatever other option is shown) 3615 is still in the loaders source (DS3615xs.yml) https://github.com/fbelavenuto/arpl/tree/main/files/board/arpl/overlayfs/opt/arpl/model-configs did you try 3615 with tcrp? this one is based on arpl but seem to lack 3615, maybe try 3617 instead https://github.com/AuxXxilium/arc you could also try to use tcrp with dsm 6.2.4 and 3617 as possible choice, that would also result in a kernel 3.10 based config at least 6.2.4 seems still be supported in the tcrp loader https://github.com/pocopico/tinycore-redpill/tree/main/config/DS3617xs

thanks, anything you can say about the source of the i915 driver? was it build from vanilla kernel 5.x source or do we have patch to mod the kernel (i have not seen 7.1 kernel source so far and i if synology works as expected we wont seen any 7.1 source before the release of 7.2)

that was part of what i wrote here (i also set up a dva1622) https://xpenology.com/forum/topic/65408-automated-redpill-loader-arpl/?do=findComment&comment=438456 -default mod for synoinfo.conf only works with one nic (maxlanport=1), it needs manuall tweaking that is not for beginners, it should detect all nic's and set synionfo.conf accordingly or make it 4 as fixed setting - it might also need more when it comes to mac adresses (netif_num=1 as default needs to be set to 2 or more and mac2, mac3, ...) - atm its problematic to have more then one nic what you need in the loader is the same as with jun's loader (grub.cfg ), netif_num=3 and mac1=..., mac2=..., mac3=..., in arpl it might be the easier way to use the full editor that comes at the end when configuring the loader to make this changes, the default dialog for the mac address makes it nor very intuitive that part might get same better implementation/guidance in the loader as its 100% controlled by the loader but its tricky to get things changed in dsm's synoinfo.conf from the loader (and needs to be doen by the people coding the loader) the part in the loader config file will make three nic's available from the kernel but to make dsm use it you also need to change synoinfo.conf, its a old problem and only comes up with units that come with a low default like 918/920/dva1622, in systems that come with pcie slots from synology there is a higher default like 4 or 8 nic's as its possible to add a pcie nic so you need to at least set maxlanports to three in /etc.defaults/synoinfo.conf an reboot i think its possible to just set the maxlanports an skip the rest to make it work https://xpenology.com/forum/topic/12679-progress-of-62-loader/?do=findComment&comment=92682 there can be a problem when the onboard nic lands behind the added dual-port nic, as nic3, then dsm will not use the onboard for initial setup but one of the dual ports, so it might be needed to swap the cable around or connect all tree ports to see whats the right one working port but as we dont have any auto correction from the loader (as done for max disks in 918+ from jun's loader) you will loose the tree ports on updates replacing the synoinfo.conf (non updateX updates, the bigger ones), if you configured static ip's to the nic's and then it will happen that your nic3 onboard is not available anymore and you will need to connect again the port that is nic1 by default to get back access to change synoinfo.conf again, good thing if that port is just dhcp or you know the ip address and netmask so you can configure another computer for that network to access dsm and change synoinfo.conf back to maxlanports="3" i do have that problem with my main system but as i know about it and can deal with a lot of stuff that can happens it no problem, but most people might correct that once when installing and after a year might have forgotten about that and panic if they "loose connection" to the dsm system after a update afaik the issue is not addressed in any of the new loaders as its not that common (most business grade types like 3615/3617/3622 come with 4 or more lan ports as default configured)

if thats working then i guess most problems with intel qsv and newer cpu's should be solved (i'm not going to install any thing like baidu netdisk, guess we will just wait for a more common source)

you could try arpl loader, i remember a case with a acer hardware where it did no work with tcrp but with arpl