IG-88

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?

 

Share this post


Link to post
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

 

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
On 9/4/2020 at 5:50 PM, ztielong said:

I received a new extra from Stan_G, if you need, please leave your email address, I'll forward to you.

I'd like it too please

tomdotcom@gmail.com

Share this post


Link to post
Share on other sites
4 hours ago, tomdotcom said:

I'd like it too please

tomdotcom@gmail.com

why so secretive?

i could add a link in the 1st post if there is good enough description for the file

or the creator just makes a new topic in the "Additional Compiled Modules" areas

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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!

Share this post


Link to post
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.