IG-88

you could try the modded alx driver from the latest extra.lzma for 6.2.3, kernel code in network area is usually not changed by synology so i guess it should still work patching that into kernel source 4.4 was simple, there is already support for E2400 and it only need minor changes right below that E2400 stuff atheros, alx: reg.h #define ALX_DEV_ID_E2500 0xe0b1 main.c { PCI_VDEVICE(ATTANSIC, ALX_DEV_ID_E2500), .driver_data = ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG },

if had it different in 6.x you either had a match by accident or you installed package moddind the behavior you can have the real info shown with this https://xpenology.com/forum/topic/13030-dsm-5x6x7x-cpu-name-cores-infomation-change-tool/

might depend on you definition of "see", the display in the dsm gui is static and only shows what the original synology unit would have the 24 is based on the kernel config that synology published for 3622 you net to look into the log (type "dmesg" in the console) or maybe try "cat /proc/cpuinfo"

yes its the same old for 3615 and 918+ but 3617 got to the same as 3622 as it was raised in kernel version to 4.4 and its 24 threads

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ it depends on what you need and also if there are drivers available for the hardware in question if you want lsi controller then 36xx is better choice bat you cant have intel quick sync video with there units especially with all the different new units in rp loader it can get even more complicated and you have more options nvme support is now in all units but not in 3615, intel qsv can only be used 918/920 but the number of cpu threads is limited to 8 on these its still a hacked appliance and there is no "one fits all", for now there is no guide that will help to select a unit beside the old one from above the some limits are different now with 7.0.1 , like max cpu threads for 3617 and 3622 is 24 now but other still exist like min 4th gen intel for 918+ and there is still a max. when intel qsv is involved as the driver synolog uses is from 12/2017 and there is no support for some newer igpu's like 11th gen or above

its redirected to com1, if you have that and use a null-modem cable you can use terminal program like putty to display that (on another computer) this thread is about dsm 6.2.2 and jun's loader so we are done here i guess please open new topic in another area

don't use a version that's out only for days, use a tested version and wait until you read about all features you need to be working whats wrong with 7.0.1? it gets updates and has all the new features already just because its the latest does not mean it the best for what you want/need

atm i have the option to test with a i5-10210u, device id 9B41, CometLake-U GT2 [UHD Graphics] will be interesting to see what happens your patch does contain more then just remapping the newer device id's to older devices but i expected intel to have more code in the last 4 years to add support for 10th gen gpu's, what newer version of the i915 driver did you use as base? anything about firmware of the driver you used as base for the patch? what version of firmware was used in this driver?

he had a "i915.patch" earlier in the thread, that would be the one to patch syno's kernel and compile the modules also keep in mind its still the same driver (syno's from end 2017) i gave that stuff some thought too (and some testing) and my suggestion would be to at least make the added i915 manually optional or split it in two drivers, one autodetect with only approved devices detected (can be made in the script code or in the driver itself) and one "experimental" where people would be able to test if the hardware in question is working or not, the thing with the two drivers would make is necessary to switch of the autodetect driver when activation the experimental driver as wen know from the 6.2.3 patch testing there are conditions where the system will not boot anymore and without proper indications for user if problematic to add a driver that might stall systems when the driver is added with autodetect in the end it was my goal to find out if non supported hardware like higher tier 10th gen or 11th could be tested with different older hardware drivers (even skylake) we know from 6.2.3 test that 9Bc5 is a problem case and switch that one through different hardware positions in the driver was one thing to test, the other thing to test was using newer firmware files too, so there would be a lot of testing for just one device a few days ago i could get a 10th gen notebook so would have a non supported güu hardware that i could switch through different older hardware types (one problem to solve was that it had no sata at all not even for a odd, but i use a m.2 to pcie 4x adapter now to "extranally" connect a ahci sata controller 1st step would be to implement i915 default driver as extensions with all needed firmware files if that is working with the original i915 driver compiled from kernel source (mo mods yet) and is replacing syno's driver from dsm *.pat file then we could start making adjustments like adding new devices known to work (the driver in 7.x is still the same as in 6.2.3/6.2.4),making it easier for some people that had it working with 6.2.3 my plan for the easter weekend was to test with that 10th gen notebook gpu to find out if there is hope for newer devices to work with that ancient driver syno is using so if anyone has time left it would be good to make the 1st step from above and ready a extension for i915

man würde da eher raid5 nehmen, weniger verlust und ein den meisten fällen ist die performance eher von iops abhängig so das man io intensive sachen auf ein extra ssd volume legt, konventionelle hdd's sind ja eher die für datengräber bei os meinst du das proxmox? denn bei dsm wird das system über alle platten als raid1 verteilt, ALLE außer ssd cache platen klingt eher nach einem hypervisor problem da das dsm system auf jeder platte ist sollte es immer hochkommen so lange noch wenigstens eine platte übrig ist such also mal eher beim proxmox nach dem problem mit baremetal xpenology liegst du in der regel wesenlich näher an der convenience einer original unit, hypervisor ist eher interessant wenn man viele andere vm's hat und dsm nur eine davon ist

what dsm version? 920+ is only available for 7.x if you already use 7.x than try DVA3221 from rp loader, platform is denverton and it was lately added in tinycore too that one comes with build in nvidia drivers

I think firstly I try boot up redpill without any add-ons, and if PHY not be worked i try to use different drivers modules... chip was referring the the network chip itself and phy chip to the chip responsible for the network physical layer https://en.wikipedia.org/wiki/PHY#PHY both features of the hardware you use, if a older driver recognizes the the network chip but not the phy chip it will also result in a non working system, newer driver might have support for that newer phy chip and would work it was often seen on 6.2.3 with intel onboard nic's and with realtek's r8125 (2.5G nic) and the usual fix was to use the latest driver

that would be called "overwriting the partition table"

the thing i can see that it might be a newer driver then @pocopico's, his might be the old one from kernel 4.4.180 and the one bb-qq uses as base is realtek's r8152.53.56-2.15.0 (one year old by now) , afair i used realtek's driver for my 6.2.3 extra.lzma bb-qq added support for EDC-QUA3C-B and ASUS USB-C2500 (https://github.com/bb-qq/r8152/commits?author=bb-qq) but as long as you dont have that specific one the reason was simply a outdated driver and that was the reason i aske to check the log, it usually would show when the driver is loaded

my extra.lzma has a newer driver then jun's original (that one was made years back), there can be newer revisions or phy chips that will need a driver made/compiled from newer driver source at least intel does provide one driver fitting all cases (same for realtek), i also have seen drivers where every oem had its own revision with custom firmware files making it a puzzle game to get them all together to create a driver that fits all hardware available

there is definitely no support for intel 2.5G nic (driver "igc") because its only supported in kernel 5.x and synology uses 4.x (intel does not support older kernels with a driver) 1G and 10 G should work in general and if not it should be possible to make newer driver from here https://sourceforge.net/projects/e1000/files/

i'd say check the result, if its already installed then after finishing with tinycore the custom.gz (1st partiton of the loader) should contain the extension and if thats ok start dsm and ckeck if the driver is present and check the log about the driver (maybe is trying to load but there is a error), if the driver is present you can also try to load it with insmod and check the result in the log and with lsusb

assuming that you have 918+ you would check if there are devices in /dev/dri if not check /lib/firmware/i915/ if there are only two files you might need more to make fill use of the driver the pci id of the gpu would be 8086:22b1 the driver in 7.x is still the same as in 6.2.3 so you could check the list of id's from here https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ (iGPU device ID's supported by synology's i915 driver) if firmware is missing you can download the extra driver for 918+, extract the firmware files (extra.lzma\extra\usr\lib\firmware\i915\) and copy them to /lib/firmware/i915/ check cpu load, if it high in general then check if hardware transcoding in video station is on also check to disable "HDR Tone Mapping", not sure it that is present in videostation but seems to be a problem with plex https://xpenology.com/forum/topic/47387-poor-plex-transcoding-performance/

918+ as it gives you more options like using intel quicksync for hardware transcoding, you cpu would not be shackled (918+ has a limit of 8 core, ht included) you might choose 920+ but thats new in tinycore and you could "migrate" to it later if you see any need (goes pretty much for all models) 3622 has cpu core limit of 24 and might be better choice if lsi sas controllers are involved because there are lsi sas drivers natively in that model as stated above its no choice for life, you can change the loader and migrate the installation into another model if you thin kit suits you better (like the dva model if nvidia support is of interest)

imho WOL is still the same as it always was, if you have your real mac configured then it should work, you can check the results of tinycore by looking into the grub.cfg of the 1st partition of your usb flash drive (\boot\grub\grub.cfg, mac1=...) same goes for the extensions, there is a custom.gz on the 1st partition and the things in there are used when starting the loader, so you can check by openg it with a packer like 7zip

check that the extension acpid is added its part of pocopicos redpill loader (that is in his tinycore) so it should be there https://github.com/pocopico/redpill-load/tree/master/redpill-acpid

also wenn du bromolow angibst, das ist 3615 die 3617 ist broadwell und 1621 ist v1000 kann man u.a. hier nachlesen wenn man es nicht aus im kopf hat https://kb.synology.com/en-global/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have nein

that depends on how you define "all models" the git repository's of dogodefi and jumkey have some more models and pocopico seems to have taken over some but not all and there are also not all dsm versions supported in the example ixgbevf, there is 3615 and 3617 supported for 7.x but only 3615 supported for 6.2.4 and as example for the models, there are references to RS4021xs+, FS6400, DS2422+, DVA3219 - so it depends if you use tinycore or not and WHEN tinycore was used/configured (its work in progress and there are new additions like 920+ lately from jumkey) a view whats to come in tinycore might be that https://github.com/pocopico/redpill-load/tree/master/config some versions are not needed anymore (like 7.0 or 7.0 beta as there is 7.0.1 and 7.1 beta and RC are replaced now by 7.1 release) and i guess will be removed on a cleanup and even some models might not be needed because of redundancy (3617 would be replaced by 3622, 918+ would be replaced by 920+) its getting hard to track and maintain all these so i guess there will be some cleanup in the future and having 2 or three units sharing the same capabilities does not make sense (like 920+ with geminilake having the same feature set as 918+ with apollolake) maybe even 6.2.4 might not be continued because even synology will only support it for some time (afair EOL 6/2023)

did you read about how DiskIdxMap is working? like here https://xpenology.com/forum/topic/32867-sata-and-sas-config-commands-in-grubcfg-and-what-they-do/ config SYNO_DISK_INDEX_MAP bool "Modify Disk Name Sequence" depends on SYNO_FIXED_DISK_NAME default y help <DSM> #19604 Add boot argument DiskIdxMap to modify disk name sequence. Each two characters define the start disk index of the sata host. This argument is a hex string and is related with SataPortMap. For example, DiskIdxMap=030600 means the disk name of the first host start from sdd, the second host start from sdq, and the third host start sda. in theory both contradict as the 1st controller has 6 ports but you idx give it just two ports available (00 and 01 and 02 is give to the 2nd controller) as you can see all 8 disks it seems all posts are mapped and the four ports skipped of the 1st controller are not used (maybe used as esata in qnap's hardware?) DSM QNAP 1 7 2 8 3 5 4 6 5 3 6 4 7 2 8 1 so its nicely in pairs as if 4 x 2port current DiskIdxMap is 00020406 you want it the other way around last pair 1st (starting 00) the one before that is to be ssen in dsm as 2nd pait starting with 02 ... so its 06040200 the only problem is that the order on the last controller is swapped, resulting in only nearly good mapping for fixing the 2 1 to a 1 2 you could try sata_remap or DiskSeqReverse (see link above in the tutorial section, you can extend the hidden part to read about all the stuff synology has) so it would be DiskSeqReverse=0002 or DiskSeqReverse=2000 and if that does not work for you you can try the other (remapping ports) sata_remap=7>8:8>7 or sata_remap=0>1:1>0 its two variety's for the command because i'm not sure if its done before DiskIdxMap is executed or after it

if you see here about extensions https://github.com/pocopico/rp-ext ixgbevf is not included in ixgbe, its a separate one and you might need to add it you can also check about the dsm type and version supported right now by checking the "rpext-index.json" in the extensions folder https://github.com/pocopico/rp-ext/blob/main/ixgbevf/rpext-index.json "ds918p_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds918p_25556.json", "ds918p_41890": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds918p_41890.json", "ds918p_42218": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds918p_42218.json", "ds918p_42621": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds918p_42218.json", "ds918p_42661": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds918p_42218.json", "ds920p_42621": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds920p_42218.json", "ds920p_42661": "https://raw.githubusercontent.com/pocopico/rp-ext/master/ixgbevf/releases/ds920p_42218.json" 918+ would be supported for 7.0.1 (42218) and 7.1 (42661) and even 6.2.4 (25556)