Jump to content
XPEnology Community

Driver extension jun 1.03b/1.04b for DSM6.2.3 for 918+ / 3615xs / 3617xs


Recommended Posts

6 minutes ago, DSfuchs said:

Must I take an other J3455 systemboard, or a Loader v1.03b DS3615xs? if so, which file version should it be (rd.gz zImage extra.lzma extra2.lzma) on partition 2 of the boot-stick.

is there a non-virtualized Xpenology solution for 2.5GbE realtek nic?

Link to comment
Share on other sites

1 hour ago, IG-88 said:

me too, you dont give much detail about your hardware, what cpu/systemboard, any additional controllers? is the r8125 a added 2nd nic or onboard?

try using synology assistant and check the versions of loader

recoverable can be a mismatch of installed dsm and loader, like having 6.2.3 on disk and bootig with a vanilla loader from jun's image that contains the kernel of 6.2.0

letting dsm fix it does result in a bootable system - but maybe your state is different

if you see 6.2.4 with assistant then start from scratch, copy img of the loader again and remove partitions from disk

 

for what reason you put a diffrent dsm 6.2.2 on the loader? it sure does not work as the drivers for 6.2.2 and 6.2.3 are different

just stick to the versions in this thread, if you want to copy a kernel to the loader then use a matching 6.2.3 files

I hope my new information below is helpful.

Link to comment
Share on other sites

1 hour ago, DSfuchs said:

I'm looking for any configuration that runs from scratch/zero with RTL8125 nic.

my suggestion would have been to install with the onboard nic and after dsm is running checking the r8125

its much easier to look for problems in a running system by checking /var/log/dmesg

the alternative might be a serial console and some system dont have a com port anymore and its also more difficult to do

 

adding changing driver can be easy, copy newer extra.lzma to the loader, boot and you are done

if dsm/xpenology is to cumbersome maybe try open media vault, dsm is a closed appliance, omv is a real linux based on a major distribution

 

1 hour ago, DSfuchs said:

- versions of loader is 6.2.2.24922 according to your instructions on page 1

no, the whole thread and even the topic is about 6.2.3, there is a extra thread for 6.2.2 and in the 1st post in this 6.2.3 thread i tried to explain the difference and that its not meant to be used wit 6.2.2, when you update from 6.2.2 to 6.2.3 you will need new drivers as the 6.2.2 drivers are incompatible and the drivers (added drivers) are in the extra.lzma

i refer to the 6.2.2 as of reading it and that's about the procedure when updating or how to handle the files in general

its not a howto or tutorial more grown and pieces added,

1 hour ago, DSfuchs said:

Must I take an other J3455 systemboard, or a Loader v1.03b DS3615xs

no, might even be harder as 1.03b needs csm mode in uefi bios and also legacy/non-uefi usb boot device

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

 

1 hour ago, DSfuchs said:

is there a non-virtualized Xpenology solution for 2.5GbE realtek nic?

sure, the extra.lzma's from the 1st post have r8125 drivers, not the latest but at least most of the r8125 cards will work and some people use r8125 cards

 

 

 

Link to comment
Share on other sites

6 minutes ago, IG-88 said:

my suggestion would have been to install with the onboard nic and after dsm is running checking the r8125

its much easier to look for problems in a running system by checking /var/log/dmesg

the alternative might be a serial console and some system dont have a com port anymore and its also more difficult to do

 

adding changing driver can be easy, copy newer extra.lzma to the loader, boot and you are done

if dsm/xpenology is to cumbersome maybe try open media vault, dsm is a closed appliance, omv is a real linux based on a major distribution

 

no, the whole thread and even the topic is about 6.2.3, there is a extra thread for 6.2.2 and in the 1st post in this 6.2.3 thread i tried to explain the difference and that its not meant to be used wit 6.2.2, when you update from 6.2.2 to 6.2.3 you will need new drivers as the 6.2.2 drivers are incompatible and the drivers (added drivers) are in the extra.lzma

i refer to the 6.2.2 as of reading it and that's about the procedure when updating or how to handle the files in general

its not a howto or tutorial more grown and pieces added,

no, might even be harder as 1.03b needs csm mode in uefi bios and also legacy/non-uefi usb boot device

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

 

sure, the extra.lzma's from the 1st post have r8125 drivers, not the latest but at least most of the r8125 cards will work and some people use r8125 cards

 

 

 

6.2.3 is still the my project. 2.5GbE USB-Sticks are working well Xpenology and my native ARM DS214+ with the available spk.

Now I will have a look to a running system by checking /var/log/dmesg

Link to comment
Share on other sites

15 minutes ago, IG-88 said:

my suggestion would have been to install with the onboard nic and after dsm is running checking the r8125

its much easier to look for problems in a running system by checking /var/log/dmesg

the alternative might be a serial console and some system dont have a com port anymore and its also more difficult to do

 

adding changing driver can be easy, copy newer extra.lzma to the loader, boot and you are done

if dsm/xpenology is to cumbersome maybe try open media vault, dsm is a closed appliance, omv is a real linux based on a major distribution

 

no, the whole thread and even the topic is about 6.2.3, there is a extra thread for 6.2.2 and in the 1st post in this 6.2.3 thread i tried to explain the difference and that its not meant to be used wit 6.2.2, when you update from 6.2.2 to 6.2.3 you will need new drivers as the 6.2.2 drivers are incompatible and the drivers (added drivers) are in the extra.lzma

i refer to the 6.2.2 as of reading it and that's about the procedure when updating or how to handle the files in general

its not a howto or tutorial more grown and pieces added,

no, might even be harder as 1.03b needs csm mode in uefi bios and also legacy/non-uefi usb boot device

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

 

sure, the extra.lzma's from the 1st post have r8125 drivers, not the latest but at least most of the r8125 cards will work and some people use r8125 cards

 

 

 

 

21 minutes ago, IG-88 said:

my suggestion would have been to install with the onboard nic and after dsm is running checking the r8125

its much easier to look for problems in a running system by checking /var/log/dmesg

the alternative might be a serial console and some system dont have a com port anymore and its also more difficult to do

 

adding changing driver can be easy, copy newer extra.lzma to the loader, boot and you are done

if dsm/xpenology is to cumbersome maybe try open media vault, dsm is a closed appliance, omv is a real linux based on a major distribution

 

no, the whole thread and even the topic is about 6.2.3, there is a extra thread for 6.2.2 and in the 1st post in this 6.2.3 thread i tried to explain the difference and that its not meant to be used wit 6.2.2, when you update from 6.2.2 to 6.2.3 you will need new drivers as the 6.2.2 drivers are incompatible and the drivers (added drivers) are in the extra.lzma

i refer to the 6.2.2 as of reading it and that's about the procedure when updating or how to handle the files in general

its not a howto or tutorial more grown and pieces added,

no, might even be harder as 1.03b needs csm mode in uefi bios and also legacy/non-uefi usb boot device

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

 

sure, the extra.lzma's from the 1st post have r8125 drivers, not the latest but at least most of the r8125 cards will work and some people use r8125 cards

 

 

 

 

22 minutes ago, IG-88 said:

my suggestion would have been to install with the onboard nic and after dsm is running checking the r8125

its much easier to look for problems in a running system by checking /var/log/dmesg

the alternative might be a serial console and some system dont have a com port anymore and its also more difficult to do

 

adding changing driver can be easy, copy newer extra.lzma to the loader, boot and you are done

if dsm/xpenology is to cumbersome maybe try open media vault, dsm is a closed appliance, omv is a real linux based on a major distribution

 

no, the whole thread and even the topic is about 6.2.3, there is a extra thread for 6.2.2 and in the 1st post in this 6.2.3 thread i tried to explain the difference and that its not meant to be used wit 6.2.2, when you update from 6.2.2 to 6.2.3 you will need new drivers as the 6.2.2 drivers are incompatible and the drivers (added drivers) are in the extra.lzma

i refer to the 6.2.2 as of reading it and that's about the procedure when updating or how to handle the files in general

its not a howto or tutorial more grown and pieces added,

no, might even be harder as 1.03b needs csm mode in uefi bios and also legacy/non-uefi usb boot device

https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

 

sure, the extra.lzma's from the 1st post have r8125 drivers, not the latest but at least most of the r8125 cards will work and some people use r8125 cards

 

 

 

Yes, but it works only for the first boot and installation.

These few people all seem to be using virtualized Xpenology to me.

Link to comment
Share on other sites

23 minutes ago, DSfuchs said:

Yes, but it works only for the first boot and installation.

if using jun's loader with its 6.2.0 kernel then it would imply the driver is not working with 6.2.3 as when installing the kernel of 6.2.3 gets copied to the loader and on next boot it's kernel 6.2.3 with the driver (extra.lzma), but the thing is the driver is made for 6.2.3, it might work with 6.2.0 but should work with 6.2.3

it would be possible to see that in dmesg if 6..2.3 starts and r8125 is just used as additional 2nd nic

Link to comment
Share on other sites

16 minutes ago, IG-88 said:

if using jun's loader with its 6.2.0 kernel then it would imply the driver is not working with 6.2.3 as when installing the kernel of 6.2.3 gets copied to the loader and on next boot it's kernel 6.2.3 with the driver (extra.lzma), but the thing is the driver is made for 6.2.3, it might work with 6.2.0 but should work with 6.2.3

it would be possible to see that in dmesg if 6..2.3 starts and r8125 is just used as additional 2nd nic

I only tried to start with the instructions on page 1. This has nothing to do with 6.2.3. That is where the journey should go. Please indicate any combination that should work. I try all of them.

Link to comment
Share on other sites

3 hours ago, DSfuchs said:

Must I take an other J3455 systemboard, or a Loader v1.03b DS3615xs? if so, which file version should it be (rd.gz zImage extra.lzma extra2.lzma) on partition 2 of the boot-stick.

Any information here going 6.2.3 with DS3615xs loader?

Link to comment
Share on other sites

21 hours ago, DSfuchs said:

Any information here going 6.2.3 with DS3615xs loader?

 

i already answered this

https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/?do=findComment&comment=198248

 

21 hours ago, DSfuchs said:

This has nothing to do with 6.2.3.

 

it does, this whole thread is about 6.2.3, not any other older version, there are other threads with dsm version numbers like this one specific for 6.2.2

https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/

 

21 hours ago, DSfuchs said:

That is where the journey should go. Please indicate any combination that should work.

 

i did that:

On 4/20/2020 at 2:56 AM, IG-88 said:

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

 

 

21 hours ago, DSfuchs said:

I try all of them.

its a complex matter and synology has no intentions to make it smooth for us

as already stated, its not a tutorial or step by step how to, you could also read 1st posts of the threads for loader 1.03b/1.04b to get a better picture, on long term its better to understand why its working or not

Link to comment
Share on other sites

Hi @IG-88,

 

I have a quick general question, to the best of your knowledge, is there case where overwriting the rd.gz and zImage files with the ones from the Synology PAT (DSM) files could cause issues? Could we default to overwriting the usb partition 2 rd.gz and zImage files regardless of installation type (every time we create a bootable usb device)?

 

Hopefully this question makes sense and if you need any elaboration let me know.

 

Thanks

Link to comment
Share on other sites

On 3/31/2021 at 4:07 AM, timi691222 said:

Can DS918+ add LSI-9305 driver?

 

the driver in 0.13.3 supports the following

1000:0064
1000:0065
1000:006E
1000:0070
1000:0072
1000:0074
1000:0076
1000:0077
1000:007E
1000:0080
1000:0081
1000:0082
1000:0083
1000:0084
1000:0085
1000:0086
1000:0087
1000:0090
1000:0091
1000:0094
1000:0095
1000:0096
1000:0097

 

and here is the list

https://pci-ids.ucw.cz/read/PC/1000

 

your is this one https://pci-ids.ucw.cz/read/PC/1000/00c4 ?

the lsi sas drivers in 918+ are problematic as you can see in the 1st post, i would recommend using 3617 as it comes with newer drivers from synology

this would be whats supported in 3617 right now (and with smart and serial and without problems about that it might kill your raid if disk hibernation in on)

so you 1000:00c3 would be supported in 3617

1000:0064

1000:0065

1000:006E

1000:0070

1000:0072

1000:0074

1000:0076

1000:0077

1000:007E

1000:0080

1000:0081

1000:0082

1000:0083

1000:0084

1000:0085

1000:0086

1000:0087

1000:0090

1000:0091

1000:0094

1000:0095

1000:0096

1000:0097

1000:00AA

1000:00AB

1000:00AC

1000:00AD

1000:00AE

1000:00AF

1000:00C0

1000:00C1

1000:00C2

1000:00C3

1000:00C4

1000:00C5

1000:00C6

1000:00C7

1000:00C8

1000:00C9

1000:00D0

1000:00D1

1000:00D2

1000:02B0

 

 

On 3/31/2021 at 4:56 PM, sojab0on said:

cant we try to pass the nvidia dedicated gpu dev ids trough in an extra driver for the jun loader and test it with passtrough of a gpu to see if that can make it work for transcoding as well

please use the forum search to find the attempts in that direction, its not that easy, its more then just a driver (*.ko file) that would be needed

i have this one on my list but there might bo one or two more threads

https://xpenology.com/forum/topic/22272-nvidia-runtime-library/

it looked like it was possible to just use the drivers from a "compatible" dsm version but as already stated it gets way more complicated as ffmpeg and other are involved,way more then i'm willing to do as i don't need that, i provided drivers and ways on how to build them, so other people with enough time to spare can push this forward if there is enough will to do it

 

 

20 hours ago, shrabok said:

is there case where overwriting the rd.gz and zImage files with the ones from the Synology PAT (DSM) files could cause issues?

every case where it does not match the installed version (on disk, raid1 over all disks) it a issue

usually dsm will not boot and offer a repair that usually copy's the kernel files from disk back to the loader

 

20 hours ago, shrabok said:

Could we default to overwriting the usb partition 2 rd.gz and zImage files regardless of installation type (every time we create a bootable usb device)?

i do mention this i the 1st post (afaik), as i'm only offering the extra/extra2 its up to the user to copy the (6.2.3) files to the loader, before using it

how would you want to do that automatically? in theory its possible to offer pre-made (modded) loader with newer kernel files and matching extra/extra2

i'm not doing this for legal reasons, any one is free to offer this, either jun nor me have copyrights on that stuff and as long as there is a decent description with that loader making clear in what way its different from jun's original and giving the version of the extra/extra2 thats used i dont think there is anything to complain about

 

i dont mind if anyone uses the extra/extra2, i would prefer to see a version number, not my name, to be used with it to give people a way to see if its the recent version and being able to read about problems and quirks

i've seen my extra/extra2 been used in some stuff from china (like 1019+ loader) and i dont mind that, its free to use for everyone and if anyone tells people its his work then i dont mind too

at some point i started to add checksums to the download to make sure people can check if its the version from me or anything modded and i may add some version text file to the extra/extra2 to make it easier to check what version is in use (extra/extra2 can easily be unpacked with 7zip to check a text file)

 

so if you feel the need to offer loaders for pre configured for 6.2.3 feel free to do so and open a thread in the loader section (might need to be approved by a mod so it can be a few days before everyone can see it)

btw before doing so PM me, i have a way to overcome the read/write problems in win10 so the offered loader would also be easier to handle as both partitions could be used freely in win10, auto mount drive letters and working without "as administrator" (as in older win10 version)

 

  • Thanks 1
Link to comment
Share on other sites

20 hours ago, IG-88 said:

so if you feel the need to offer loaders for pre configured for 6.2.3 feel free to do so and open a thread in the loader section (might need to be approved by a mod so it can be a few days before everyone can see it)

btw before doing so PM me, i have a way to overcome the read/write problems in win10 so the offered loader would also be easier to handle as both partitions could be used freely in win10, auto mount drive letters and working without "as administrator" (as in older win10 version)

 

 Thanks @IG-88, i've been working on automating the creation of the Xpenology bootable usb drive in OSX using Ansible and as I was automating the process I thought "why not just overwrite the rd.gz and zImage files every time you create the USB disk". So my question was out of concern that I could possibly hit an edge case where this wasn't the fact. From what I understand from your response is, this shouldn't be an issue. 

Link to comment
Share on other sites

I went out and bought a i3-10100 because it was reported to work on 918+ for transcoding Plex.

 

Unfortunately i cannot get it to work at all.

 

Steps I've done:

1. installed 918+ using the 1.04b loader and 13.3 driver file (because I have a 8125 2.5 GB nic.) Install goes off without a hitch, works perfectly.

2. I downloaded the most recent update to the i915.ko file "918plusdsm623u3i915mod2_1"

3. Extracted it, copied over an folder share then to /usr/lib/modules/. I give it the same properties as all the other .ko files (644) and changed ownership of it to root/root.

4. Rebooted, system does show the loader grub and the following screen. About 5s later the screen shuts off. And the system is not responsive at all. I am guessing the system hangs. 

 

So i reinstalled the system and instead of copying to /usr/lib/modules, I copy it to /root and then set the chmod and chown as the others. Then as I have seen others in this thread do, i used the insmod command to install it. The screen goes black and that is all she wrote, system is now locked up again.

 

I have tried all 3 versions of the moded i915.ko file and they all result in the same crash/lock.

 

If I put in a discreet video card, the system boots and runs normally. I can then remove the i915.ko and Xpenology works again without issue.

 

Is the 13.3 driver set at fault here? Do i need to use an older version? I don't know how far back I would need to go to keep the rtl8125 driver.

Edited by rok1
  • Like 2
Link to comment
Share on other sites

1 hour ago, rok1 said:

Rebooted, system does show the loader grub and the following screen. About 5s later the screen shuts off. And the system is not responsive at all. 

The same CPU and the same problem. It's a headache!😥

Edited by Three
  • Like 1
Link to comment
Share on other sites

4 hours ago, rok1 said:

So i reinstalled the system and instead of copying to /usr/lib/modules, I copy it to /root and then set the chmod and chown as the others. Then as I have seen others in this thread do, i used the insmod command to install it. The screen goes black and that is all she wrote, system is now locked up again.

 

I have tried all 3 versions of the moded i915.ko file and they all result in the same crash/lock.

that it happens with all 3 versions makes it odd, only one version containing the right device id should do anything the other should just just pass as it has no device 9bc8 in the driver to lock on

it does work that way with synology's original i915.ko or you would not be able to boot at all

the version you used is from/for U3 (not tested if it makes a difference when using it with plain 6.2.3), check if you have 6.2.3 u3 installed

the "older " version are for original 6.2.3 and u2 (as in the description of the downloads)

Edited by IG-88
Link to comment
Share on other sites

5 hours ago, IG-88 said:

that it happens with all 3 versions makes it odd, only one version containing the right device id should do anything the other should just just pass as it has no device 9bc8 in the driver to lock on

it does work that way with synology's original i915.ko or you would not be able to boot at all

the version you used is from/for U3 (not tested if it makes a difference when using it with plain 6.2.3), check if you have 6.2.3 u3 installed

the "older " version are for original 6.2.3 and u2 (as in the description of the downloads)

 

 

Definitely have u3 installed (but tried manually installing the baseline 6.2.3 and subsequent updates by blocking internet, then using one of the earlier mod drivers from the first post, same outcome). A fresh install of XPE automatically downloads/updates 6.2.3u3. (although I think I was getting 6.2.4 from install at one point this morning as the system would fail to boot on first reboot, I went through about 10 reinstalls before I just started with the 6.2.3 pat from Synology and let it update to u3 on its own.)

 

The good news is I can recover the system easily by installing a discreet gpu as it disables the onboard iGPU, so all is not lost for testing. The lockup I experienced with this 10100 is the same that happened with the 10700. I wish Xpe would do proper log management (renaming .1, .2 etc) so we could see where it's hitting a snag

 

part of the driver is loading:

root@Xpenology:~# lsmod | grep i915
i915                 1238212  0
drm_kms_helper        119660  1 i915
drm                   304204  2 i915,drm_kms_helper
iosf_mbi                4234  1 i915
fb                     34811  2 i915,drm_kms_helper
video                  25321  1 i915
backlight               6096  2 i915,video
button                  4692  1 i915
i2c_algo_bit            5328  2 sfc,i915

 

I take that back, I was able to recover logs from when when it locked up. You can look and see if any of it is relevant.

 

oops panic

Edited by rok1
Link to comment
Share on other sites

1 hour ago, rok1 said:

same that happened with the 10700

this gpu is different 9bc5 and thats the same as the already confirmed non working from 10900

 

for the 10100 you can try if it make a difference when you disable vt-d in bios and if the video out is connected to a monitor or not

i dont know if newer i915 driver iterations might have a separate firmware for the comet lake's gpu's, if so we could try to load these dmc firmware instead of the old kaby lake we are using now (i'm not sure about the cnl firmware already in the driver and where that one is used)

maybe "cnl_dmc_ver1_07.bin" or "icl_dmc_ver1_09.bin" could be used

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

i would need to read a little about the newer gpu's

 

Link to comment
Share on other sites

2 minutes ago, IG-88 said:

this gpu is different 9bc5 and thats the same as the already confirmed non working from 10900

 

for the 10100 you can try if it make a difference when you disable vt-d in bios and if the video out is connected to a monitor or not

i dont know if newer i915 driver iterations might have a separate firmware for the comet lake's gpu's, if so we could try to load these dmc firmware instead of the old kaby lake we are using now (i'm not sure about the cnl firmware already in the driver and where that one is used)

maybe "cnl_dmc_ver1_07.bin" or "icl_dmc_ver1_09.bin" could be used

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

i would need to read a little about the newer gpu's

 

I have read on the web that the 10th gen and newer have different firmware from 9series and earlier, and that might be part of the problem. 

Link to comment
Share on other sites

24 minutes ago, rok1 said:

I have read on the web that the 10th gen and newer have different firmware from 9series and earlier, and that might be part of the problem. 

 

that what i'm not so sure about, as its still gpu gen 9.5 in comet lake

https://en.wikichip.org/wiki/intel/microarchitectures/comet_lake#Architecture

 

intel has no new DMC (Display Microcontroller) firmware for CML only GUC (Graphics microController) and HUC  (HEVC/H.265 microController) and synology only uses DMC firmware with its driver (firmware files in *.pat)

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

 

the i915 driver itself references to more kbl firmware files then just the DMC file (kbl_dmc_ver1_04.bin)

kbl_guc_ver9_39.bin
kbl_huc_ver02_00_1810.bin

they where not needed for i3-9100 cpu's to have transcoding working so not to expect that it will be the case for the same gen gpu in comet lake

Link to comment
Share on other sites

Hey, all! Has anyone managed to enable HW decoding on i3-10100T (0x9BC8) builds? Here has some negative feedback. 

 

Hardware:

CPU: i3-10100T

MB: Asrock H470M ITX-ac (has built-in rtl8125gb and intel 219-v ethernet ports)

BIOS: CPU C state disabled, VT-d enabled, Primary video output set to onboard and no dGPU installed

 

Software:

USB bootloader: DS918+_6.23-25426-1.04b.img (installed v0.13.3 extra.lzma/extra2.lzma prior to installation)

System: 6.23-25426-up3

 

How I replaced i915.ko

  1. Create a share folder and put i915.ko (for 9BC8 up3) into it
  2. sudo -i
    # enter password
    rm /usr/lib/modules/i915.ko
    cp /volume1/share/i915.ko /usr/lib/modules/i915.ko
    chmod 644 /usr/lib/modules/i915.ko
    chown -R root:root /usr/lib/modules/i915.ko
    reboot

     

Issue:

  1. Rebooting screen
  2. Showing BIOS boot-up screen
  3. Jun's mod selection screen
  4. Jun's mod Intro screen (saying this mod is brought to you by...)
  5. (After about 10 seconds)
  6. Screen turns black but not losing signal, Ethernet leds are still lit

What I have tried:

  1. Arp-scan the local network, not found
  2. Disconnected the display, reboot, and re-scan, not found
  3. Redo all procedures, the same. 

The symptom seems to be similar with i9-10900 as described in #1

Quote

-> one user negative feedback for a i9-10900 (8086:9BC5) system does not boot anymore - seems to be a solid hands off?

 

Any suggestions, folks? More information upon request! 

THANK YOU IN ADVANCE!

Edited by Sark
Link to comment
Share on other sites

2 hours ago, Sark said:

What I have tried:

  1. Arp-scan the local network, not found
  2. Disconnected the display, reboot, and re-scan, not found
  3. Redo all procedures, the same. 

Also tried

  • blacklisting host update.synology.com on gateway to forbid automatically updating from 6.23-25426 to update 3, as someone has managed to Synology HW Decoding (Emby) success with i3-10100 and he indicated he's using 6.23-25426 neither update 2 or 3.
  • re-format the disk, re-install DSM .pat and replace i915.ko, same result, black screen and ip not found. : (

 

Edited by Sark
Link to comment
Share on other sites

On 4/6/2021 at 9:51 PM, Sark said:

i checked the i915.ko files offered there (only checked the u3 files) and they where binary the same as the files offered in the 1st post (also same file date, i guess they just used my files and repacked them to match pci id's instead of dsm version)

there is still the possibility that there are different 10100 cpu around (different SKU's, like seen with the i5-9400)

i found some material but i need to check it out and compare information's but i guess there might only be one type of 10100 because on ark intel there is only one pci id for the gpu

 

its not that much of a problem for you to test it with dsm 6.2.0 and the matching modded driver

you just take you usb, replace the zImage and rd.gz on the 2nd partition with the files from the 6.2.0 (v23739) *.pat file - make copy's of the files there so you can revert it - and then use it to install 6.2.0 to a single empty disk

if you are done testing just put the kernel files from before back on the usb and reconnect you disks

(even if you boot you "old" disks with the usb that has 6.2.0 kernel files, dsm would offer to fix it an in a few seconds it would be up and running again)

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...