Jump to content
XPEnology Community

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


Recommended Posts

On 9/10/2020 at 3:31 AM, venno said:

, its my first time modding this type of file

it looks like you did not use the tool that are supposed to be used i guess - "diff"

also if comparing with a 3615/17 synoinfo.conf then there are more settings then just maxlanports=4

eth2_mtu="1500"
eth2_wol_options="d"
eth3_mtu="1500"
eth3_wol_options="d"

 

 beside the part in the "upper" part of jun's patch  there is also the lower part where the file /usr/sbin/init.post is patched

that also contains changes like

+_replace 'esataportcfg="0x10"' 'esataportcfg="0x0"' /tmpRoot/etc.defaults/synoinfo.conf
+_replace 'internalportcfg="0xf"' 'internalportcfg="0xffff"' /tmpRoot/etc.defaults/synoinfo.conf
+_replace 'maxdisks="4"' 'maxdisks="16"' /tmpRoot/etc.defaults/synoinfo.conf

you where skipping to add the changes there, why?

what about extra2.lzma?

 

Link to comment
Share on other sites

Hi IG-88

 

Thanks for replying, can you expand on this comment I am unsure of what you mean/refer to:

 

5 hours ago, IG-88 said:

it looks like you did not use the tool that are supposed to be used i guess - "diff"

 

I had missed the lower part of the patch file and I guess would need to add:

 

+_replace 'maxlanport="2"' 'maxlanport="4"' /tmpRoot/etc.defaults/synoinfo.conf

 

I found the extra.lmza and extra2.lmza similar so made my mods to both files, for brevity I only posted the extra.lmza for comment, or does the extra2 require different modification?

 

I ignored the wol options as I did not think it important in my use case or do they need to be specified for programming reasons to enable the mtu values to be changed?

 

I came about the lan ports mod when I had issues with my new 918+ baremetal install only seeing 2 nics, I observed that when I modified the file '/etc.defaults/synoinfo.conf' and changed this value to 4 I got my additional 2 ports to appear in DSM. I decided to try and make this change permanent in the loader and began to investigate. I don't know the ins/outs of how the loader fil;es work but based on observation of the contained code I made the following assumptions:

 

1. The override file probably passes in values to the DSM that override the set ones in either the kernel or loader files (or both maybe)

2. Both lmza archives would require the same mods to the same files

3. I should endevour, where possible, to place code mods in the loader on a line  where existing mods near the actual lines in the file being modified are located

 

Cheers for the help

 

Link to comment
Share on other sites

On 9/12/2020 at 5:46 AM, venno said:

I found the extra.lmza and extra2.lmza similar so made my mods to both files, for brevity I only posted the extra.lmza for comment, or does the extra2 require different modification?

the patch files in extra and extra2 are different, just look for the size of the files

7.836 Bytes vs 7.613 Bytes

 

On 9/12/2020 at 5:46 AM, venno said:

I am unsure of what you mean/refer to:

 

On 9/12/2020 at 12:12 AM, IG-88 said:

it looks like you did not use the tool that are supposed to be used i guess - "diff"

 

 

diff is a command that its used to create diff files aka the patch (it could also be named *.diff as it is the result of comparing 2 or more files with diff and getting a patch that will change the 1st file into the 2nd)

https://man7.org/linux/man-pages/man1/diff.1.html

ifaik thats the normal way to create a diff/patch file jun's jun.patch is a file containing diff's for more then one file, the normal way would be to use a original synoinfo.conf, do all the patches jun's patch does, change the additional parts you want to have, make a new patch with diff and exchange the parts about synoinfo.conf in jun.patch

and you should have a look what the lower part (kind of patch in a patch) is used for and i'd expect you would need to make changes there too

at least thats the way i would have doen it when trying to make a new (better?) patch that might also contain a upgrade to the maxdrive to 24 (but that needs even more changes like the driver pattern for internal and usb drives

 

On 9/12/2020 at 5:46 AM, venno said:

I ignored the wol options as I did not think it important in my use case

yes but it that makes further problems when using wol ... i tend to make it as good as i can, going half way and knowing there will be problems and complains is the reason i did not do that patch (beside the fact that it would need even more time i would have to invest into xpenology)

i did document this >2 nic problem and possible change about 2 years ago

https://xpenology.com/forum/topic/12679-progress-of-62-loader/?do=findComment&comment=92682

 

On 9/12/2020 at 5:46 AM, venno said:

1. The override file probably passes in values to the DSM that override the set ones in either the kernel or loader files (or both maybe)

 

as i did not really tried to make a new patch i never looked for how it plays into the boot process, might be just important for 1st boot when installing?

 

On 9/12/2020 at 5:46 AM, venno said:

2. Both lmza archives would require the same mods to the same files

 

problem here is we dont know for sure why there are two files and two patches, i did test a little and and wrote min opinion into the additional driver thread, in the end no one ever wrote about this as the use is somewhere in jun's additional kernel bzImage (1st parttition) and cant be figured out easily

i ended up to make the driver changes in both files to make sure it works under all conditions

 

On 9/12/2020 at 5:46 AM, venno said:

3. I should endevour, where possible, to place code mods in the loader on a line  where existing mods near the actual lines in the file being modified are located

 

with some luck it might work that way as the program "patch" uses a guess to apply a mismatched patch, but i also have seen this fail so if you dont try it 1st to see if iits working its much safer to do that diff/patch properly using the diff command

Link to comment
Share on other sites

On 9/10/2020 at 10:05 AM, satdream said:

By chance the overall Synology versions are available for the registered preview testers (I will not share, please don't ask), and I tried the 3617XS on an Xpenology baremetal under DSM 6.2.3-25426 Update 2.

 

The update is well accepted, and installation worked fine (btw June Loader 1.03b is still compatible 👌), with final automated reboots etc. but then it block exactly as for the install from 6.2.2 to 6.2.3 = the new DSM7.0 install reset the additional drivers and a new extra.lzma aligned with DSM7.0 is needed to restore NICs support (and I assume the other requested drivers).

 

after testing the loaders 1.03b for 3615 and 1.04b for 918+ with 7.0 preview i'd say that's not the case, the loaders do not work anymore with the kernel of dsm 7.0

jun used a "pre" kernel (bzImage on 1st partition of the loader) that is started by grub and that loads the the synology kernel and i guess that's the point where it fails, the synology kernel is not loaded properly and it fails to start, resulting in dsm not booting (drivers like extra.lzma come later into play)

i guess it needs to be the same kernel version to step from a running "pre" kernel into loading a new kernel and as synology changed the base kernel version in all three dsm versions, we have loaders for, it will not work with any of them

 

3615   3.10.105 -> 3.10.108

3617   3.10.105 -> 4.4.180+

918+    4.4.59+ -> 4.4.180+

 

all loaders throw a

va not found
Failed to process header

on the serial console when booting with the new 7.0 kernel and stop after this

(as @OllieD already wrote some days ago https://xpenology.com/forum/topic/33940-dsm-7-preview/?do=findComment&comment=164967)

 

case closed i'd say

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

On 9/13/2020 at 7:41 PM, IG-88 said:

the patch files in extra and extra2 are different, just look for the size of the files

Yes they are different sizes as they contain a differing quantity of programming lines, the syntaxs and structures in both seem the same though. I would gues that the extra2 file has less lines/content as it may serve a differnet process in the loader (possibly upgrades maybe).

 

On 9/13/2020 at 7:41 PM, IG-88 said:

ifaik thats the normal way to create a diff/patch file jun's jun.patch

I used the following post as a guide to unpack the lzma archives, modify internal files and then repack:

 

https://xpenology.com/forum/topic/14358-tutorial-modifying-104b-loader-to-default-to-24-drives/

 

On 9/13/2020 at 7:41 PM, IG-88 said:

i ended up to make the driver changes in both files to make sure it works under all conditions

I concur, did the same, better safe than sorry.

 

On 9/13/2020 at 7:41 PM, IG-88 said:

with some luck it might work that way as the program "patch" uses a guess to apply a mismatched patch, but i also have seen this fail so if you dont try it 1st to see if iits working its much safer to do that diff/patch properly using the diff command

My mistake I should have elaborated more, the lzma and also the other files I used where tested on a test install(s) to amalgamate all the mods I would need for my bare metal install. Once I was happy I performed a fresh bare metal install using all the mods/hacks I required for my HW platform, so my finally production install occured as I required with collected files and hacks.

 

The reason for posting the lzma is my near complete lack of specific knowledge of how the code I entered may affect other things (unintended consequences) and I was after comment from an experienced set of eyes. This worked, you have pointed out the part of the patch file I missed.

 

In hindsight I should have started with a slighlty older version of DSM so I could test the efficacy of my mods after performing an upgrade/update. The mods work for the latest version but may not remain functional in an upgrade scenario. I may repeat all my steps but in a VM environment to try and gain a confidence level regards upgrading.

Edited by venno
grammar
Link to comment
Share on other sites

Hi, IG-88,

my board is j4105.

DSM version 6.2.3 25426

extra.lzma v0.13.3

 

I tried to transcoding some videos with hardware acceleration and found that it didn't work

 

image.png.8d4757f302b691012fcc7d569ee66fea.png

 

image.png.a38cee22400196bec10423e5f8c76e15.png

 

the result video size is very small, and no video frame in it, just only audio data. I try transcoding command line(same MOV format video), get the same result.

 

Partial transcoding log(return video:0kB audio:159kB):

[aac @ 0x564733e9ef00] Trying to remove 128 more samples than there are in the queue
frame=  209 fps=0.0 q=-0.0 Lsize=     162kB time=00:00:09.98 bitrate= 132.7kbits/s speed=24.2x    
video:0kB audio:159kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.556809%
Input file #0 (input.MOV):
  Input stream #0:0 (video): 209 packets read (13041871 bytes); 209 frames decoded; 
  Input stream #0:1 (audio): 431 packets read (137638 bytes); 430 frames decoded (440192 samples); 
  Total: 640 packets (13179509 bytes) demuxed
Output file #0 (out.mp4):
  Output stream #0:0 (video): 209 frames encoded; 209 packets muxed (0 bytes); 
  Output stream #0:1 (audio): 430 frames encoded (440192 samples); 431 packets muxed (163090 bytes); 
  Total: 640 packets (163090 bytes) muxed
639 frames successfully decoded, 0 decoding errors

Transcoding Command Line:

ffmpeg -y -report -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i input.mov -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -b:v 10683833 output.mp4

 

the /dev/driv/ is normal,

image.png.dcf5ef5f3b86b7f31a9597b771885c63.png

 

and the driver is normal

image.png.109b1267d2786c3f880541c92e98cb32.png

 

Everything looks normal, but it just doesn't return normal results, I found an error in a section of log in DMESG, I don't know whether it is related to this, please help to confirm whether this section of log indicates that the graphics card has been driven normally

 

Quote

[   12.450705] [drm] GuC: No firmware known for this platform!
[   12.450709] [drm] HuC: No firmware known for this platform!
[   12.451182] [drm] VT-d active for gfx access
[   12.451275] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   12.451276] [drm] Driver supports precise vblank timestamp query.
[   12.451351] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   12.452047] [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
[   13.515590] systemd-udevd[6736]: starting version 204
[   13.530743] [drm] failed to retrieve link info, disabling eDP
[   15.751334] [drm] GPU HANG: ecode 9:0:0x6bf56ac4, reason: Hang on bcs0, vcs0, vecs0, action: reset
[   15.751410] i915 0000:00:02.0: Resetting bcs0 after gpu hang
[   16.956694] [drm:gen8_reset_engines [i915]] *ERROR* bcs0: reset request timeout
[   16.964034] i915 0000:00:02.0: Resetting vcs0 after gpu hang
[   18.169750] [drm:gen8_reset_engines [i915]] *ERROR* vcs0: reset request timeout
[   18.177121] i915 0000:00:02.0: Resetting vecs0 after gpu hang
[   18.227003] ip_tables: (C) 2000-2006 Netfilter Core Team
[   18.240752] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[   18.313716] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   19.381805] [drm:gen8_reset_engines [i915]] *ERROR* vecs0: reset request timeout
[   19.389315] i915 0000:00:02.0: Resetting chip after gpu hang
[   22.098969] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout
[   24.395968] i915 0000:00:02.0: i915_reset_device timed out, cancelling all in-flight rendering.
[   24.917092] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout
[   27.735213] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout
[   27.843129] i915 0000:00:02.0: Failed to reset chip
[   27.859631] [drm] Initialized i915 1.6.0 20171222 for 0000:00:02.0 on minor 0
[   27.860735] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   27.861362] acpi device:54: registered as cooling_device4
[   27.861440] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input1
[   27.863853] [drm] Cannot find any crtc or sizes
[   27.864908] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   27.892211] Btrfs loaded, crc32c=crc32c-intel
[   27.898541] exFAT: Version 1.2.9
[   27.947889] jme: JMicron JMC2XX ethernet driver version 1.0.8

 

 

dmesg.txt transcoding_log.txt

Edited by fangzhen2005
Link to comment
Share on other sites

On 9/16/2020 at 11:44 AM, fangzhen2005 said:

Hi, IG-88,

my board is j4105.

DSM version 6.2.3 25426

extra.lzma v0.13.3

 

I tried to transcoding some videos with hardware acceleration and found that it didn't work

 

 

Turn off the VT-D and it will work normally!!!

 But there is a problem, if VT-D is needed, hardware acceleration and VT-D,  I have to choose one or the other?

Link to comment
Share on other sites

Hello,

 

The only loader and version I could get working on my hardware is the 1.04b (DS918+) with 6.2.3

Asrock x570m, Ryzen 3400g. So far so good after a few days of troubleshooting.

 

However I am planning on using an Asus XG-C100C (based on Aquantia  AQC-100?)

I see there are extra.lzma for the DS3615, 3617 and DS916+ found at https://xpenology.com/forum/topic/9508-driver-extension-jun-102bdsm61x-for-3615xs-3617xs-916/

 

Were these drivers included in "extra918plus_v0.13.3"? Because I can't get the card to detect.

 

My config is set as follows :

 

set mac1=7 (snip) 9 (Asus)
set mac2=2 (snip) 3 (Intel from mobo)
set netif_num=2  (I assume this tells it to look for 2 NIC's? Otherwise I'm not sure what's missing.)

 

aside from VID/PID/SN the rest is all default.

 

Thanks!

Link to comment
Share on other sites

15 hours ago, acbranduro said:

I tried to download extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.3 from http://s000.tinyupload.com/?file_id=66035132371971554733 but tinyupload is not working. Could someone please provide this file somehow different?

 

Sent you a PM. Let me know if it works and I'll post the link here until tinyupload works again.

Link to comment
Share on other sites

В 22.09.2020 в 17:27, IG-88 сказал:

i added new temporary links, looks like i will have to look for a new reliable free and anonymous upload option that keeps the files online for long enough

Hi,

what is the best network adapter for syno?
I tried the HP NC550SFP, but with it the syno sometimes disappeared from the network and had to reboot the system, now I installed the Mellanox X2 - it works without such problems.

I thought to put Intel X520-DA2

Link to comment
Share on other sites

On 8/27/2020 at 6:32 PM, T-REX-XP said:

Anybody has realtek 8168 network card?? I have faced with some issue on the last extra.lzma(13.3), the maximum speed of copying one big file is 17MB/s via the samba.

Also I have tried USB 3 network adapter, with the same file and cable and receive 70-80 MB/s  It looks very strange for me. The system shows connection speed as 1000Mbps,Full duplex, MTU 2000

 

 

Here is some details about hardware:


0000:03:00.0 Class 0200: Device 10ec:8168 (rev 15)
        Subsystem: Device 1b0a:01a5
        Flags: bus master, fast devsel, latency 0, IRQ 90
        I/O ports at d000 [size=256]
        Memory at d0604000 (64-bit, non-prefetchable) [size=4K]
        Memory at d0600000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
        Capabilities: [170] Latency Tolerance Reporting
        Capabilities: [178] L1 PM Substates
        Kernel driver in use: r8168

 

 

I have similar problem with Realtek 8168 on TerraMaster F2-421.

I installed by using extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.3 and everything seems ok except network speed.

Speed is unstable and slow:

admin@NasBoss:/$ iperf3 -c 10.10.2.51
Connecting to host 10.10.2.51, port 5201
[  5] local 10.10.2.11 port 35010 connected to 10.10.2.51 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.08   sec  29.0 MBytes   226 Mbits/sec    0    214 KBytes
[  5]   1.08-2.00   sec  10.0 MBytes  90.8 Mbits/sec    0    214 KBytes
[  5]   2.00-3.00   sec  9.36 MBytes  78.5 Mbits/sec    0    214 KBytes
[  5]   3.00-4.00   sec  34.6 MBytes   290 Mbits/sec    0    214 KBytes
[  5]   4.00-5.00   sec  91.9 MBytes   771 Mbits/sec    0    214 KBytes
[  5]   5.00-6.00   sec  11.1 MBytes  92.9 Mbits/sec    0    151 KBytes
[  5]   6.00-7.00   sec  8.75 MBytes  73.4 Mbits/sec    0    212 KBytes
[  5]   7.00-8.00   sec  14.9 MBytes   125 Mbits/sec    0    212 KBytes
[  5]   8.00-9.00   sec  63.1 MBytes   530 Mbits/sec    0    111 KBytes
[  5]   9.00-10.00  sec  79.0 MBytes   663 Mbits/sec    0    211 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   352 MBytes   295 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   351 MBytes   294 Mbits/sec                  receiver

iperf Done.
admin@NasBoss:/$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.10.2.51, port 58149
[  5] local 10.10.2.11 port 5201 connected to 10.10.2.51 port 58150
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  16.2 MBytes   136 Mbits/sec
[  5]   1.00-2.00   sec  6.62 MBytes  55.6 Mbits/sec
[  5]   2.00-3.00   sec  3.55 MBytes  29.8 Mbits/sec
[  5]   3.00-4.00   sec  2.53 MBytes  21.2 Mbits/sec
[  5]   4.00-5.00   sec  34.3 MBytes   288 Mbits/sec
[  5]   5.00-6.00   sec  10.9 MBytes  91.2 Mbits/sec
[  5]   6.00-7.00   sec  3.98 MBytes  33.4 Mbits/sec
[  5]   7.00-8.00   sec  32.0 MBytes   269 Mbits/sec
[  5]   8.00-9.00   sec  2.59 MBytes  21.7 Mbits/sec
[  5]   9.00-10.00  sec  75.6 MBytes   634 Mbits/sec
[  5]  10.00-10.14  sec  8.72 MBytes   539 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.14  sec   197 MBytes   163 Mbits/sec                  receiver

Did I use wrong drive extension?

Link to comment
Share on other sites

in theory adapter that work with the drivers delivered in dsm will be best as they should even work when no additional driver is working and usually synology will maintain the driver if needed

 

https://xpenology.com/forum/topic/14127-guide-to-native-drivers-dsm-621-on-ds918/

https://xpenology.com/forum/topic/13922-guide-to-native-drivers-dsm-617-and-621-on-ds3615/

 

3617 might have some newer drivers over the 3615 (like with the mpt3sas)

 

your hp card uses be2net.ko as driver, never used such card myself, the driver is the one from the kernel (3.10.105) so its pretty old

there are sometimes firmware updates for hardware components requiring a newer driver version - you would need to dig deeper on hp to review problems and cases like tis one

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00016433en_us

could be you new a newer firmware, could also be you need a older to work properly

if its not working with older yet you could try newer firmware

 

i use a older broadcom card (not native), a older qnap tehuti based (compatible with synology aka native) and e newer tehuti oem (needs newer driver and phy firmware)

all three 10G cards

 

"older" mellanox was often used as they where cheap to buy and are native in 3615/17 so your mellanox seems to be a good choice

Link to comment
Share on other sites

2 hours ago, merve04 said:

what really defers them appart?

Does version 12 just reinclude juns original mpt2sas/mpt3sas driver found in the 1.04b loader?

 

in 12.1 the files raid_class.ko, scsi_transport_spi.ko, scsi_transport_sas.ko are the files that came with jun's original loader, they base either on synology's 3 year old beta kernel source (22259) or vanilla source from kernel.org

when compiling with the "recent"  6.2.2 (24922) source then smart and temp is gone but its working stable with disk hibernation, some one with c++ knowledge would need to dig through synology's kernel source to find out why (i do have a hunch but its pretty time consuming to find out and might be useless in the end)

it seems to be about base functionality that is independent from the hardware driver (mpt2sas/mpt3sas)

 

in 13.3 the 3 files are made from 6.2.2 kernel source (we don't have 6.2.3's source) working safely but missing smart functionality

in contrary to 3615/17 scsi/sas in no base of the kernel for 918+ as its released from synology, there does not seem to be a missing dependency (missing kernel module) but still there is something wrong/missing, might be a dead end when its something that's can't be loaded by a module (like we have with hyper-v support)

 

2 hours ago, merve04 said:

But updated i915 driver?

short:

jun's driver is gone

 

longer:

when using jun's original extra/extra2 with 6.2.3 then the other drivers work again because the change from 6.2.2 was reverted, but with the changes in the 6.2.3 kernel source for synology's new i915 driver now prevent jun's i915 from loading and at the same time jun's driver renders synology's new driver useless as it is not loaded

 

extra long:

in synology's 4.4.59 based 918+ kernel was only the vanilla kernel.org i915 driver, that was ok for synology as they only wanted support up to apollolake but that left out newer cpu's for us

a newer i915 driver (backport by jun) was added with loader 1.04b, that driver was able to make intel qsv available up to coffeelake

when synology launched the 920+ geminilake based units lately they needed a newer driver and as 7.0 was not ready they had to backport a newer i915 driver themself, they used a slightly older version then jun did and also did it the synology way and that was incompatible to the way jun did it, they might have taken some additional patches to make it run better with geminilake, in the end 6.2.3 came with a i915 driver that seems to work better then jun's (now over 2 years older implementation)

so since 6.2.3 my extra/extra2 does not contain jun's additional kernel modules for i915 and also removes them from disk (update folder) when still present - the loader only updates or add files from extra/extra2, no delete from disk if not present in extra/extra2, but files in update are loaded before the normal path so if jun's driver is present in update it prevents synology's new driver from loading (and jun's driver does not work with the changes from kernel in 6.2.3)

 

 

 

Link to comment
Share on other sites

45 minutes ago, merve04 said:

the same results with 6.2.3 using v0.12.1?

I never have and never will use hdd hibernation, power is not a concern to me.

yes without hdd hibernation it should be fine

 

 it would be possible to make a extra/extra2 with all drivers original jun, only leaving out the i915 stuff and a slightly mod to the patch to removes the old i915 if present (that would only be needed when its not a fresh install but to make it work under all conditions it should be present)

but that version would only work as intended (hardware transcoding support) when used with 6.2.3 so consequently it should be a complete loader with the new 6.2.3 kernel files on the 2nd partition, that way it would only be possible to install 6.2.3 or newer with that loader version - but i'm not going to distribute a whole loader, some one else would need to do this, i would only provide extra/extra2 and instructions on how to finish the loader (which i already did in the line above)

 

Link to comment
Share on other sites

14 minutes ago, -iliya- said:

is a sound good - may be you know good cheaper 2x10Gb port nic for syno?

maybe this

thats a ConnectX-3, thats even on the official list from synology

https://www.synology.com/en-global/compatibility?search_by=products&model=DS3617xs&category=network_interface_cards&filter_brand=Mellanox&p=1

 

afaik these are supported be the driver that synology has in 3615/17

ConnectX MT254xx
ConnectX-2 MT264xx
ConnectX-3 MT275xx
ConnectX-IB MT276xx
ConnectX-4 MT277xx

 

only newer x-5/6 cards are not supported (might be possible from external  source)

Link to comment
Share on other sites

Dear friends I'stucked trying grup recognize my new SATA Card (I added 4 to a Gigagyte b365 with 6ports) . So, firstly DSM 6.2.3 recognize it, and works ok, but after re-start o block-out doesnt recognize directly. I have to disconnect data cable from new Card , and restart againg DSM, after hot plug again cable, and works again. I don't knwo how to edit a config grub or install windows drivers to DSM.. could anyone give me some tips ? thk very much in advance. 

 

card added

https://www.amazon.co.uk/Rivo-Controller-88SE9230-HyperDuo-Technology/dp/B07NQ58MR6/

Link to comment
Share on other sites

17 minutes ago, Mary Andrea said:

Dear friends I'stucked trying grup recognize my new SATA Card (I added 4 to a Gigagyte b365 with 6ports) . So, firstly DSM 6.2.3 recognize it, and works ok, but after re-start o block-out doesnt recognize directly. I have to disconnect data cable from new Card , and restart againg DSM, after hot plug again cable, and works again. I don't knwo how to edit a config grub or install windows drivers to DSM.. could anyone give me some tips ? thk very much in advance. 

 

the chip in general should work, the driver is ahci and part of synologys kernel, is you suspect a driver/kernel issue you could try migrating to ds3615, that uses a older kernel compared with 918+ (you did not write which of the 3 possible types you installed)

 

might be quality issues with the card or heat problems

the later can be checked by inspecting the heat sink, is it a good fit, as the heat sink is removable you could remove it and check the thermal solution, maybe its a rubber pad and its not working properly, you could try removing it and replace it with normal thermal grease as used for cpu's

 

if you can send it back and get you money back that might be a solution too, i'd suggest a JMB585 based 5port controller, this chip has pcie 3.0 support,also uses 2 pcie lanes, resulting in double bandwidth compared to the controller you have (max 1000MB/s vs max 2000MB/s)

 

  • 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...