IG-88

intel 2.5G are not as good and safe as there 1G nic's https://www.guru3d.com/news-story/intel-is-experiencing-network-issues-the-i226-v-controller-is-prone-to-connection-loss.html cant say anything from personal experience but as a pcie nic i might take a realtek as its way cheaper (less then half) and intel seems to struggle with its 2.5G tech (2nd time, 1st was in 2020 when they messed up the 1st iteration on 2.5G nic's and some board oem's had to suffer) but there is support for intel's 2.5G nic's even for dsm 7.x and its kernel 4.x as of Jim Ma and his backported igc driver (intel only supports kernel 5 integrated drivers, no separate driver for older kernels - also here realtek is better then intel now) - but seen from the practical side you could use both intel or realtek with xpenology's dsm 7.x https://github.com/jim3ma/synology-igc https://github.com/fbelavenuto/arpl-modules/tree/main/src/4.x/drivers/net/ethernet/intel/igc https://github.com/pocopico/rp-ext/tree/main/igc

there is no consent about that, they just don't tell you about that function and its ability to variably change what is done on you system and the name "punish" for the function is a clear intention to do harm, active insight is that kind of collection but the synowedjat-exec is part of DSM itself and i'm pretty sure a lot of business customers will have compliance issues if synology can upload and execute code at any time, collect data at any time of any data stored on the system and can also "punish" for whatever they think is not within of there view of legal or compliant - and what happens if they get hacked? all units reachable by internet are at risk of a takeover - yeah sure they have consent about that from all customers btw. the link still works, you just removed the "tt" in the visible part (text of the link)

you can do it in the loaders menu (if it has one) or in its config file (same place where you define the mac address for you network card) the sn is used as kernel parameter when the loader begins to start dsm's original kernel it pretty much the same as with jun's old 6.x loader, only difference is that you did it in 6.x loader in the grub.cfg and now its stored in a xml file maybe re-read the howto for configuring the 7.x loader again, there is a part where the sn is configured (usually as random generated but there is also a option to manually enter one and thats where you have to go) alternativ is to uninstall SS and install the old version manually as spk file https://archive.synology.com/download/Package/SurveillanceStation/9.0.2-10061 "SurveillanceStation-x86_64-9.0.2-10061_openvino.spk"

synowedjat-exec is build-in imho this might need more attention and discussion found the same post in a chinese forum https://imnks.com/7800.html i also found way older references like this from 2021 http://www.nasyun.com/thread-78105-1-1.html and there are some references about consuming cpu power on other forums wedjat seems to refer to "wedjat eye" aka "Eye of Horus" https://en.wikipedia.org/wiki/Eye_of_Horus "... that represents well-being, healing, and protection ...", so its synology's eye on "there" systems some people might see it more like this https://en.wikipedia.org/wiki/Palantír ? synowedjat-exec seems to be present since 2020 (DSM 7.0) DSM_7.0 beta 40850 came without it DSM 7.0 beta 41222 already came with it - that was 12/2020 so it looks like synology is actively collecting data for years and the question is what are they doing with this data and active (root) access to the systems as there are no information on what they collect (could even be the data you host on the nas as the content what is downloaded for collection or "punishment" can change at any point) it does rise some serious questions and seen from European law (GDPR) there could be interesting legal follow up's from that and who watches the watchers? edit: my gripe here is about synology making the rules, investigating, judging and punishing, all in one instance without control/transparency and in a democratic system there is a problem with that (or at least it should be or its not a democratic system), https://en.wikipedia.org/wiki/Separation_of_powers

up to 10th is working now on units supporting i915 driver already (918/920/dva1622 or anything based on apollolake/geminilake as dsm plattform, plattform can be seen in the name of the update *.pat file and these have the same kernel settings so usable modules should be the same, example would be 1019+, also supported in tcrp and there should be i915 support) https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/ 11th will be possible now with sa6400 (early version for testing) because it comes with kernel 5.x and the i915 driver does not need that much backporting as it would with kernel 4.x and 12/13th might come later with that one (already worked on but not in the test version yet), that also might open the way for any other unit coming with kernel 5.x to have i915 driver even when its not in the kernel settings by default as it is the case with apollolake/geminilake https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/?do=findComment&comment=440534

it's stuck in firmware update mode (driver for update not unloaded), a small hack how to get it working is here https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/?do=findComment&comment=440597 atm i'm running my test system with just the realtek onboard

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