IG-88

that would be my guess too, reconnection errors usually originate from cable problems, the value refers directly to s.m.a.r.t. "UDMA_CRC_Error_Count" also did a run of creating a raid5 with the 2nd jmb585 controller and 3617, no reconnection errors thats odd, the "normal" link speed is 6.0 Gbps

why not using lsusb to identify the device and the use udev's blacklist to get rid of it (in dsm)

if you can provide a pci vid and pid and its sub vid/pid we could check but if its running with 5.2 its so old i'd say its guaranteed to work with 6.2.3 (at least when using my extra.lzma with more und newer drivers), the driver would be e1000e and thats part of jun's default extra (from 2018) just take a new/empty usb put on the loader for 6.2.3 (3615/17, needs csm/legacy if its uefi bios) shutdoen you system, remove 5.2 usb und put in the new (dont worry about usb vid/pid as long as you dont install it does not matter), boot the new usb and try to find the system in network with synology assistant, just booting the loader wo not do anything to you disks in optimal case you will see the system and it would offer update/migration - at this point you know network is working and also storage to be working (to see the old dsm system it needs to access the disks) with 6.x you would need ahci mode on the sata system so i dont expect any driver problems for the nic, trouble to expect is having ahci mode and booting in csm mode when its uefi (you need to use the non-uefi usb boot device) if you have trouble with the new loader open a new thread in area that matches

whats the hardware and dsm type? any cache drives involved? - i did have btrfs trouble with my main system after trying write cache with two sata ssd's and had do revert to my last backup anything in /var/log/ about disk errors? the log in the webgui are not that helpful if it comes to analyze problems

there are some disk specific log files and the general "messages" log imho the safe way to exclude any dsm/driver related problems would be to change to loader 1.03b and migrate to 3617, no nvme and hardware transcoding with that but it has synologys lsi sas drivers they use for the business units, thats supposed to work stable, with 918+ is still added and not as safe as the "original" (as we can see with the smart and hibernation problems) by using 3617 (at least temporary) you could rule out some factors to drill down to the source of the problem did the same thing with my system, just swapped the loader and installed dsm 3617 over the 918+, can be reverted the same way, just insert the "old" 918+ loader and install 918+

no thats apipa and dsm does this https://en.wikipedia.org/wiki/Link-local_address atm i cant see a problem all 10G ports get DHCP addresses when the router is connected to the swich its working as it should nothing wrong with the drivers or dsm, anything else is a logical network problem that depends on the configuration not sure whats you want to do or achieve or whats not working for you

??? dsm uses normal linux mdadm software raid and lvm2 for SHR, every linux would be able to use this if its done right and even synologys KB references to linux for data recovery of dsm disks you could install open media vault on a media (not the dsm disks) boot it up and you should see you data volume here is a howto on doing it with a normal linux manually https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/ depends whats more important to you and if you want to spend money for newer hardware you still can redo a 5.2 loader and use 5.2

tehuti based, the driver is in my extra.lzma and should work as the driver edimax offers is from 2017, my driver in newer for sure

can you try a live linux from usb, the speed sounds like you are running the nic with 100MBit, check speed led and settings in dsm, check cable, check switch

why not 6.2.3 did you use a set of extended/newer drivers? the i219 might need a newer driver then the one from 6.2.0 https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ yes, thats predefined in the loader as patch making sure you get repatched when updating dsm you should learn some linux basics or you will be in deep trouble when things doe not go as intended, dsm might look flashy and easy to use but thats not true for xpenology as its a hacked appliance and sometimes it does not behave like a original dsm system no more like this, but the patch was already precisely pointed out with /var/log/disk_overview.xml (if thats the right file) with linux there is no drive letter, its "THE" disk or "root" file system and everything is in it so "/" is the start like "C:\" ... maybe plan one or two weekends to get the basics., there are plenty of websites and youtube videos afair the reconnet counter is a s.m.a.r.t. value of the disk, so its not just rewriting a file, you would need to reset it on the disk look for "udma_crc_error_count"

same result with 3617, no problems, no reconnects maybe its a problem with that controller, vendor or board design can you provide a picture and a source where you bought it? mine looks like this i also had a m.2 card with a jmb585 and that one never was stable, but it has more problems then reconnects i do have a 2nd card in another system i might swap for the one i use for testing, same board design bought later from a different brand i've seen at least two other board designs

if all 4 ports are connected and the switch is connected to the router (that does dhcp) the all 4 should get addresses, if its not working for both there is something wrong with the configuration, might be vlan on the microtik (seems unlikely that the switch would block dhcp) if you assign addresses manually its ok as long as its outlide the dhcp area, you dont want a ip address to be used on two systems at the same time

i guess you main problem might be that the original bios will only boot from a usb device with usb vid/pid f400/f400 so you might need to copy the content of the internal usb module (as backup) and then write the xpenology loader to it i can't say for sure as i did not test it and last time someone wanted to do that his usb modules was not working anymore

that one is ahci, so the kernels build in ahci driver is used, no extra driver file, its already in the precompiled kernel from synology you should be able to use it just by plugging it in (as long as its below the max. drive values, 12 for 3615/17)

winxp came without a build in ahci driver so to get it working the sata ports where often uses in ide/compatibility mode when installing sure why not, its just a special driver problem with dsm 6.x we have here, nothing in general

do the 2 ports on the pc get a dhcp address? you could try to configure the ip addrerss manually on the 10G nic's to see if you can ping the 10G ip address of the nas from the pc (remove the 1G cable from the 10G switch when trying it)

1st run 918+ 6.2.3, mix of different 2.5"/3.5" disks (5+2 JMB585/582), created a RAID6 WDC WD5000AAKX Seagate GB0750EAFJK Seagate ST500DM002 HGST HTS725050A7E630 WDC WD3200BEVT HGST HDS5C4040ALE630 Samsung ST500LM0 not a single reconnect i will try with 3617 next

lsi sas controller? 918+ has issues when disk hibernation is active, 3617 is the best alternative in that case (beside not using disk hibernation) can also be psu and maybe a cable problem did you check the logs in /var/log/ ?

ob das mit der extr/extra2 geht sieht man daran das es etwas unter /dev/dri gibt ob das mit der nutzung der transcodierung geht sieht man an der cpu last, das kann man sich entweder mit htop auf der commandozeile ansehen oder in der webgui außerdem kann man die logs in /var/log/ ansehen ob man da fehler sieht

if its kernel related you would be able to use 918+, both boards are for 4th/5th gen intel cpu's so if one of the systems is still without data you could try to create a shr, raid5/6 with 1.04b 918+ DSM 6.2.3 did the reconnects happen to all disks on the jmb585? on my other system with 3617 and jmb585 there are 0 reconnects with 4TB seagate disks so far no reconnects with hitachi disks and jmb585/582 and 918+ next run tomorrow will be 3617 with seagate, wd and hitachi hdd's

the ahci is part of synologys kernel, so its not important what extra.lzma you are using what can make a difference is if its 918+ or 3615/17 because of 4.4.59+ vs 3.10.105 kernel had a pcie 1x jmb582 card (same as jmb585 but just 2 ports) and tryied with two 500GB hitachi disks as raid1 and filled the whole disk, nothing shown so far when opening disk health i will try with the jmb585 next and do a raid migration from 1 to 5 with a 3rd disk, should result in plenty of disk activity (atm testing with 918+) i have a bunch of 500GB disks around among them seagate and wd and there are also some smaller ssd from crucial and samsung i can test with

schau mal auf die cpu auslastung wenn du 918+ dsm 6.2.3 mit hardware trascoding nutzen willst brauchst du auch meine extra/extra2.lzma sonst läuft der i915 treiber nicht (kollision zwischen synologys i915 angepasstem 6.2.3 kernel und jun's i915 treiber) https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/

afair it was about ide compatibility when using sata with older systems (WinXP and older?)

https://xpenology.com/forum/topic/24864-transcoding-without-a-valid-serial-number/ nein, der geht ootb

the lsi sas controller can compensate for the pcie 2.0 by using up to 8 pcie lanes, the jmb585 and asm1166 only use 2 pcie lanes, so on numbers the lsi sas can be twice as fast as the jmb585 on the pcie bus atm the jmb585 is just in the backup systems and thats offline most of the time i will try to replace it there and see if i can have the jmb585 in my test hardware