IG-88

i've only tested with 6.2.3 (1st boot without dsm) but it should work with 6.2.0 too, but not for long, when you install 6.2.3 *.pat the kernel is overwritten with 6.2.3 "accidental" update also starts with 6.2.3 on usb the path is the same as with 6.2.2, i suggest 1st creating the usb with 6.2.3, test it and the install the dsm pat file with a 6.2.3 booted loader (it will recognize tthe older version on disk and will offer to update/migrate) no, not related and your xeon does not have a gpu like a desktop cpu, quick sync video is a gpu feature nothing what i did, if its solved then its part of the i915 driver synology provided you could try a fresh install on a single empty disk to test if there is a general problem with your i3-9100 cpu i tested with a G5400 aka coffee lake S, UHD 610 gpu Gen 9.5 and your i3 9100 is a coffee lake R with UHD 630 gpu gen 9.5 so there might be a difference (my own i3 9100 is still in its original package, but i will know soon if its working or not) did you had 6.2.3 kernel with my new drivers on usb? any log (serial console or from disk)? i've tested igb and e1000e with additional nic's so i know it should work in egneral

edit 14.05.2020: 6.2.3 is back online as v25426, for newer coffeelake cpu's with problems using hardware transcoding (dev/dri present after boot) there is a new videostation that fixes the problem https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/?do=findComment&comment=144918 edit2 02.06.2020: as @richv31 pointed out here https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/?do=findComment&comment=148564 there seems to be a serious problem with 918+ and scsi/sas drivers, at least with mpt2sas/mpt3sas, not just with 6.2.2/6.2.3 it also happens with jun's original loader 1.04b and dsm 6.2.0 (23824), breaking raid sets after not properly waking up from hdd hibernation means potential data loss i had a two disk raid1 set on a lsi 9211-8i and after disks spinning down only one came up and i saw some really worrying messages on the serial console, i was not able to log in to the system, not on the web gui, even not on the serial console, the whole system was in lock down and only switching off seemed to work as of the problems with not getting s.m.a.r.t. values i used juns old original raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko to get the old state back (replacing my newly made ones from more recent synology kernel source 24922 ) in 0.11/0.12 - these version inherit the problem that seems to be present since the beginning with loader 1.04b anyone using mpt2sas/mpt3sas and disk hibernation on 918+ should disable it for now to not risk any data loss the new 0.13 for 918+ will have the raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko from kernel source 24922, that version did work on testing on my system without breaking anything and without such alarming errors on wakeup of disks, there will be no smart data but at least it seems safer then disks not waking up properly for "proper" lsi sas controller support i'd suggest using 3615 or 3617 as it is "native" in these units and should work better, maybe there are kernel options missing in the 918+ kernel and that cant be fixed, if anyone finds out more just add a comment (i might not have the time to dig into this) the other alternative is to use sata/ahci instead of scsi/sas with 918+, that works without problems on my system using 918+ (12 disks), JMB585 based controller seem to be the best choice atm as they support pcie 3.0 and can have up to 2000 MByte/s for its 5 sata ports (the older marvell and asm chips use only pcie 2.0 limiting the data rate to 500 MB/s or 1000 MB/s, even 8 port controller with two of the older chips use a pcie bridge chip with just two lanes making them terrible choice for a high port count - might be ok with just one or two 1GBit nic's but will at least limit the rebuild speed and ssd's should be kept away from these controllers and place in internal sata ports) for Instructions about installing or updating please read "Driver extension jun 1.03b/1.04b for DSM6.2.2 for 3615xs / 3617xs / 918+" if i have time i will write more in this place the new package is not well tested i just did some tests with hardware i have at hand (ahci, e1000e, r8168, igb, bnx2x, mpt2sas/mpt3sas) and tested update from 6.2.2 to 6.2.3 basically synology reverted the kernel config change made in 6.2.2 back to what was before so old drivers from original 1.04b loader (and older driver i made before 6.2.2) should work again - but as synology also introduced there own new i915 driver with 6.2.3 there will be a conflict when jun's i915 driver is loaded with 6.2.3 there are two positive new things, synology released a nearly recent kernel source code (24922) and 6.2.3 has a new i915 driver supporting as much gpu hardware as jun's backported i915 driver in loader 1.04b - so there is no need for jun's i915 driver anymore and in theory we should have good support for apollo lake, gemini lake and other newer hardware but it seems not all new UHD630 is supported as there is dev id "3E98" unsupported (i5-9400, i5-9600k, i7-9700t, i7-9700), ark.intel.com and wikichip.og are usually good sources to check the id https://ark.intel.com/content/www/us/en/ark/products/134898/intel-core-i5-9400-processor-9m-cache-up-to-4-10-ghz.html edit: there seems to be versions of the i5-9400 with a "3E92" GPU this versions don t need the patched driver, they will run with the default driver, /dev/dri should be present ootb, it also can be checked in /var/log/dmesg when searching for "[8086:3e92]" https://en.wikichip.org/wiki/intel/core_i5/i5-9400 there is also a good document from intel listing all coffeelake's https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-cfl-vol01-configurations.pdf coffeelake cup's without driver support (no hardware transcoding), SKU numbers should be listed when buying and can be checked on the box i9 SKU S82 i7 SKU S82 i5 SKU S6f2 a new 10th gen i5-10500 / i3-10300 have device id's "9BC8" and there are no "9xxx" numbers in the driver we use so don't expect any newer gen10 cpu to work with hardware transcoding even when it "only" has UHD630 igpu edit: there are also even lower end 10th gen cpus (2 core) with a different GPU device id "9BA8" like G5920, G5925, G6400 with a iGPU UHD 610, the equivalent in the 9th gen would be a G5400 and that comes with pci device id's 3E90/3E93, so we need to edit a different entry when patching for this edit: i made a modded i915 driver were the pci device id of the 9th gen UHD 630 iGPU (3E92/3E93) is replaces with the device id's of the newer/different UHD 610/630 iGPU's that are unsupported 8086:3E92 => iGPU UHD 630, Low End Desktop 9 Series (original driver) -> 8086:3E98 => iGPU UHD 630, High End Desktop 9 Series (i5-9400, i5-9600k, i7-9700t, i7-9700) 8086:9BC8 => iGPU UHD 630, Low End Desktop i5-10500, i5-10600T and lower 8086:9BC5 => iGPU UHD 630, High End Desktop i510600K and higher 8086:3E93 => iGPU UHD 610, Low End Desktop 9 Series -> 8086:9BA8 => iGPU UHD 610, low End Desktop Series like G6400 the zip file contains 3 versions in every one is 3E92 replaced with the one we want to get working, as its just a crude binary patch i choose 3E92 as it seemed the most similar device, was tested for 3E98 iGPU and seemed to work, for the 10th there is at least one positive feedback with plex its intended to be used with the extra/extra2 from this thread as this removes jun's old i915 driver (not just one file) that will prevent synologys new driver to work properly the patched i915.ko file is supposed to be copied to /usr/lib/modules/ and replaces the original file from synology for 6.2.3 Update3 (added 9BA8 support) https://gofile.io/d/4fFJA5 https://dailyuploads.net/x3e0nkxk6p0e https://usersdrive.com/zfl9csl91xwr.html https://www34.zippyshare.com/v/304gfbnO/file.html SHA256: EC2447F47FEE6457FE3F409E26B83E5BF73023310E10A624575A822FDBC10642 a little warning, in worst case the system might crash or freeze when transcoding and and such undefined states and hard resets can result i data loss (cache) or damaged raids (depending on the load of the system at this time) so until its more tested it should not be used on system with "important" data and a recent backup - ok i know its a little over cautious but i dont like the thought someone looses data because of this nice to have feature (software mdadm raids can be repaired in most cases if the worst happens) -> positive feedback for a i5-9400, i5-9600K, i9-9900T (8086:3E98) to fully working -> positive feedback for a G6400 (8086:9BA8) to have /dev/dri -> one user positive feedback for a i5-10600T (8086:9BC8) to fully working with plex -> one user negative feedback for a i5-10500 (8086:9BC8) to get /dev/dri devices but no transcoding with emby -> one user negative feedback for a i9-10900 (8086:9BC5) system does not boot anymore - seems to be a solid hands off? edit: there is a driver source patch for 10th gen that came up along 7.x and 9BC5 was confirmed to work with this new driver, so anyone with a 10th gen gpu and trouble can change to 7.x (tc rp loader) ot can try these 6.2.3 modules from this link (i915_918_623.7z) https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/?do=findComment&comment=277236 i completely removed jun's i915 drivers from the extra/extra2 and changed/added the i915 firmware needed, also i took care of the "old" i915 drivers on the installed system in /usr/lib/modules/update/, they are now deleted on boot so if you come from 6.2.2 and used extra/extra2 std or recovery or you did already used juns original 1.04b extra/extra2, it should work as soon as you boot up (when drivers in "update" are not present then the default drivers from synology will be used and with the added i915 in place it will work on most intel gpu's up to coffee lake) the driver versions are the same as in the 6.2.2 extra/extra2 but are newly compiled, as every driver from 6.2.2 is renewed all the old drivers are overwritten and there should be no crashing drivers on boot (which can prevent proper shutdown or reboot) we now have one universal i915 driver (and not jun's and synologys) its back to one package for all cpu/gpu, if needed there will be a recovery version too i only did test a new created loader from 1.04b image file with zImage and rd.gz from "DSM_DS918+_25426.pat" and the new extra.extra2, it will also work with the 6.2.0 kernel that is by default in the 1.04b image if there are problems getting hardware transcoding to work it might help to disable vt-x/vt-d in bios (reported on a J5005 Gemini Lake), but there are other possible reasons because of the licensing thats needed for this to work, but at least it will not hurt as as lon as you dint intent to use the vmm package if you accidentally updated 6.2.2 to 6.2.3 and now have problems like no network after boot, no proper shutdown/reboot or missing /dev/dri (hardware transcoding) then you just copy the new extra/extra2 to your already updated usb drive (the update to 6.2.3 already installed the new kernel on it) with latest updates of win10 there is no drive letter anymore, its possible to still do it with the tools already used for creating the usb drive, read the usb to a imgae file with "Win32DiskImager 1.0" (activate "read only allocated partitions"), mount that image with osfmount (like in the tutorial section), overwrite old /extra/extra2.lzma and write the image back to usb with Win32DiskImager extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.9 some intel and realtek driver updated so hopefully more onboard nic's will work (like realtek 8125), also realtek 8152 is newer so all 2.5G usb solutions from realtek schould work, there is still no way for the intel 2.5G nic as there is no standalone driver for older kernel versions, removed fireware, added bnxt_en and sr_mod/cdrom, nic Killer E2500, added *vf.ko in rc.modules https://pixeldrain.com/u/jHa2eYrc https://gofile.io/d/mUFYxQ 1CED32FCF63EB54DAA44335FA1EFBCE408D41A3E16D55771D35B0FD423F0B9CF extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.3 scsi/sas disks will have no s.m.a.r.t. infos with lsi sas controllers (see edit2 above), newer atlantic.ko driver 2.3.4, r8125 added to rc.modules, used latest source for realtek drivers r8101/r8125/r8152/r8168/r8169, bna.ko firmware corrected https://pixeldrain.com/u/pkBY9XjC https://gofile.io/d/FvoFdo SHA256: EF6F26999C006A29B3B37A7D40C694943100F0A9F53EC22D50E749F729347EC6 for special purpose and tests, extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.12.1 - this version shows s.m.a.r.t. info and serial of disks for lsi scsi/sas but might corrupt the raid when disk hibernation is active (see warning above) https://pixeldrain.com/u/kZJdPj1H https://gofile.io/d/nsglbX SHA256: 9089D38A4975AB212553DA7E35CE54027DE4F84D526A74A46A089FC7E88C1693 extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.12.1_test, added virtio/9p, CDROM drivers, nic Killer E2500 lhttps://pixeldrain.com/u/Rx4tV6ay https://gofile.io/d/RnX1QA SHA256: E72820BF648CFD7F6075DEEB1208A3E0D8A61F38289AE17AC7E355910B9B0E0E extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.11_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... https://pixeldrain.com/u/5aN77nWf https://gofile.io/d/PMIDrX SHA256: 5DE93F95841CC01F9E87EE4EE2A330084B447E44EBAA6013A575A935D227D4AF extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.12_test (2/2022), added virtio/9p, CDROM drivers, nic Killer E2500 https://pixeldrain.com/u/xmhCVxck https://gofile.io/d/VRtmC1 SHA256: B9AC8705D5D9DCEED1C0315346E4F2C7C4CD07C4ED519FC9901E8E368A3AE448 extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.11.2_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... (0.11.2 because i forgot bnx2/bnx2x firmware and mpt2/mp3 driver problem when updating from 6.2.2 in 0.11) https://pixeldrain.com/u/zwAJzKa9 https://gofile.io/d/0Tx8A7 SHA256: D467914E55582D238AC5EC4D31750F47AEB5347240F2EAE54F1866E58A8BD1C9

https://blocksandfiles.com/2020/04/15/seagate-2-4-and-8tb-barracuda-and-desktop-hdd-smr/ SMR: Barracuda 4TB – 5,400rpm – SATA 6gig – ST4000DM004 Barracuda 8TB – 5,400rpm – SATA 6gig – ST8000DM004 so that#s the reason for your extremely poor performace you are using SMR disks (all the 8TB disks and one 4TB disk)

the database on this site seems to be better then some of the manufacturer, this would be 6TB non-SMR https://geizhals.eu/?cat=hde7s&sort=p&xf=1080_SATA+6Gb%2Fs~11512_1.1~13745_6000~13811_6000~3772_3.5~8457_non-SMR

looks like THAT is the problem, its a SMR drive and slow is normal, blame WD for selling garbage as NAS drive

what drives exactly? maybe your new spare drive is one with shigled recording? https://blocksandfiles.com/2020/04/14/wd-red-nas-drives-shingled-magnetic-recording/

afair yes but its not going to make things worse, you would disconnect all (dsm) disks install ovm onto one separate disk and after its installed you shut down, reconnect all disk (boot from the ovm disk) and you will see if it discovers your (shr) volume (it will not discover the dsm system raid1 partitions - at least it did not as i tested it 2-3 years ago - i'm much more resilient to dsm problems now and i'm not using the "latest" dsm on my "live" system - its still running dsm 6.1 and i'm not "exposing" it to the internet)

i'm not using SHR aka lvm2 (in addition to mdadm) but afaik it shoud work too (SHR is "just" a clever combination of mdadm and lvm2) on purpose I'm using plain mdadm raid6 for my own system - makes recovery easier (if needed, and tbh i did need that once even with 2 redundancy disk - and as it should be i do have a backup too, because raid is not a replacement for backup!!!) mdadm and lvm2 are no rocket science and no exclusives to synology so its possible to recover and use SHR volumes with usual linux look for @flyride posts for help to recover problems with storage (i like to work in that field too in my spare time - but he is much more capable in that field - if you want to learn about that read his threads)

please keep in mind that advise was for dsm 6.2.2, so if you try it you should use a local stored dsm *.pat file, if you let the loader download it from the internet you will end up with 6.2.3 and that is kind of work in progress and might not work at all

yes i don't doubt that but it will not work for everyone (every hardware) and on 918+ there are three types of extra/extra2.lzma and depending on what type used it will it will "influence" the result (3615/17 does not have i915 hardware transcoding and does not rely on i915 firmware) i guess it wont make things worse to try jun's original files - but don't blame me or djvas335 if it does not and i guess it will be back to what you had before when using the extra/extra2 you used before you tried jun's originals (also no guarantees - as usual) one thing is sure, your data are still there, you just cant use them because you might have lost network access or the storage does not work to get all disks into the raid one "safe" solution might be to boot up open media vault from a external (additional) source/disk, that will give you network access to your raid (data) volume - if you need files from there - thats my personal plan "f" if i loose access when dsm does not boot (if your raid is damaged then you are beyond "f")

just be patient until romorrow, i'm working on it i could send you a link for a test i did that will work for systems using realtek nic and ahci for storage (like most mITX boards with apollo or gemini lake) i guess that can be misleading, for hp microserver you will need broadcom driver (onboard) and "no extra.lzma" can mean you used jun's default extra.lzma (part of the loader) or you deleted the extra.lzma completely from the loader the driver inside jun's default extra.lzma might work with 6.2.3 in some (lot's) cases but its not that universal to copy back jun's extra.lzma, depending on the hardware it might end in success but can also fail there will be cases where storage is not working or where network does not work (i've seen problems here with a igb.ko based network adapter, e1000e and realtek did work)

ahh yes, shortly win10 started to behave like this too and i haven't tried reading since then i guess there a a lot of tools that can create a image file 1st i have at hand atm is dmde (the free edition should be ok) https://dmde.com on start it will ask for physical devices, select the usb flsh drive, it should open in a view where you see partitions and wich the right mouse button select 1st /15.7MB) / 2nd (31.5MB) and select "create image/clone", in lower half define destination as file and save it as suggested, do it for 1st and 2nd partition and put them in a zip file (the bin/image files can be used with lot's of tool, even 7zip can open them - just if you want to have a look, osfmount should work too)

if everyone writes in her/his own language it gets messy, please write in english if you can't or feel uncomfortable doing so there are areas where native language can be used like https://xpenology.com/forum/forum/10-chinese/

i'm asolute sure about what you did you emptied your updated drivers and firmware on the already installed system (6.2.2->6.2.3 updated) you removed the drivers from the extra.lzma? repacked it and put it on you loader? and added the new firmware files to your (already installed) system and it works for you that would be in the direction what i had in mind but with a more universal touch as it would be interesting to not have to manually clean the driver and firmware (0 byte long files overwriting the files there will do the trick) - but we might not need all this in doing your experiments and questions you also did something else and that was what my question about the driver version was about - you used a 0.5 extra.lzma of mine, that version that worked before 6.2.2 (the kernel config change about "CONFIG_PCIEASPM") and would not have worked with 6.2.2 but it worked with 6.2.3 that implies there is no big change in kernel source 25423 that prevents us from making new drivers, it might be just that synology reverted the change of the kernel config made in 6.2.2 (maybe because they found a better solution like a newer driver) as a quick check i took the original 1.04b loader (jun's extra.lzma made for 6.2.0) added the new kernel (not needed) and it booted up (using the new kernel) and installed dsm 6.2.3 the only mismatch now are jun's newer backported i915 drivers, but with synololgys new own backported driver we dont need it anymore it now seems simple to build a new extra/extra2 for 6.2.3 that will have all drivers working as before, i will just remove i915 drivers, add the new firmware (there is one file different from what jun's i915 driver used) adn recompile drivers the old (pre 6.2.2) way - if there are no new obstacles that can be done by tomorrow

could you list the exact models you have? (see my edited post above about smr/pmr disks from seagate)

in theory the "syno" type nearly does what real3x did in this extra.lzma, it removes jun's i915 drivers, the difference is that i add additional i915 firmware that is supported by the i915 driver synology uses (enabling hardware trancsoding support for other cpu's like normal desktop cpu's like haswell and above up to kaby lake) maybe thats interfering here but with the "recovery" type all this firmware and drivers is overwriten with 0 byte long files making them invalid and you cant load them - that should have worked for you - so the question is did you use/test the recovery tape extra/extra2, if so there must be a flaw in my recovery type extra/extra2 as its supposed to work for all systems that dont want or can use hardware transcoding but have cpu that is capable of running 918+,kind of a safe fall back if you still have the usb you used for testing i'd like to have a look to see whats really on it

you could read your usb with "Win32DiskImager 1.0" (activate "read olny active partitions" in the gui) upload it somewhere and pm me the link, i could have a look if i see anything its all the same driver, even 8118 is the same

please post a more complete log where the version number of the used r8168.ko, i'm sure the driver from 0.5 cant word and there will be the version number from the 6.2.3 build in driver not sure what you did and why you think a much older driver should work te descrition how to unpack and repack the extra.lzma is in this https://xpenology.com/forum/topic/7187-how-to-build-and-inject-missing-drivers-in-jun-loader-102a/ you dont have to use a chroot for this, just a normal live linux would be enough

and that can be fixed easily as mentioned above, i plan to release new extra/extra2 that will invalidate the old drivers and will add the new i915 firmware files so that people with just needing native drivers and hardware acceleration will be fine (without shutdown or reboot problems)

not exactly, the untouched loader contains jun's drivers (made for 6.2.0), they will not work too people just need to wait if someone finds out why the drivers fail, for now my working hypothesis is a kernel source change after 24992 that produced this incompatibility and as we dont have the new source we cant compile new drivers to test

only 918+ does have r8168.ko its back to native drivers story for people wanting to update to 6.2.3 also there will be shutdown problems when a driver crashes on boot - like extra.lzma loads r8168.ko crashes and DSM then loads its own driver, resulting in a working network but system will have shutdown problems (does not switch off)

just a quick warning for 6.2.3 attempts, all additional drivers from 6.2.2 will fail (crash) to load so if you update only "native" drivers from DSM will work the mentioned i915 firmwares can be loaded as expected to get all non apollolake/geminilake cpu's to work (tested with a 8th gen cpu, got /dev/dri devices) looks like there is a reason why its a complete new version 6.2.3

yes and thats the problem, juns loader contains drivers for 6.2.0 and it contains i915 drivers replacing the drivers from synology so even with 6.2.3 juns drivers will be loaded you need to delete juns driver in the update folder (rm -rf /usr/lib/modules/update/*), shut down and then put the "syno" extra/extra2 to your loader when booting the drivers will be back in update folder but without i915 drivers, so dsm's own i915 will be used (and with 6.2.3 it should be with gemini lake support)

from reports i seems the J1900 will run with 918+, dsm 6.2.2 and the "syno" extra/extra2 with /dev/dri so hardware transcoding should work (in the limits what a J1900 can do) the J1900 gpu is ivy bridge level, thats good to see whats possible https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video maybe wait a few days to see if gemini lake now works with dsm 6.2.3, if thats the case there should be some reasonable priced units or did you have something in mind with more sata ports or 10G nic?

also wenn du ein bereits installiertes image benutzt dann musst du den loader nicht anpassen, das war nur gedacht falls man installieren will/muss ein fertiges image würde mit dem default loader gehen und bei updates übernimmt dsm ja die ip konfiguration, da wäre auch nachträglich nichts mehr notwendig