deadsquirrel

Thanks, I was just coming in this morning to correct that mistake - I cannot edit the post though.... How do I correct the discussion - or perhaps just delete the errant info so it isn't perpetuated. DeadS

Yes, it is - all intel integrated cpu graphics from sandy bridge ix-2xxx to ix-9xxx included, preumable the ix-10xxx as well as they are still UHD620 interfaces. Excluding the 'F' parts, of course (F=disabled GPU on chip) DeadS

lsi sas connected or ahci? ahci

Gigabyte Z390 Gaming X Howdy, reporting back. Implemented new build 1.04b ds918+ - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25423 - Loader version and model: JUN'S LOADER v1.04b - DS918+ - Using custom extra.lzma: yes IG-88 extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.11 - Installation type: BAREMETAL - Gigabyte Z390 Gaming X - CPU: Intel i3-9100 - NIC: Intel I219-V - Additional comments: Video hardware transcoding success - Plex, and Videostation with Updated Videostation workaround. (Updated Videostation workaround IG-88 post) /dev/dri - new driver has /dev/dri/Card0 - 0.10 had /dev/dri/0 interface - same hardware. CPU Frequency governor insmod ./cpufreq_ondemand.ko - FAILS with insmod ./cpufreq_ondemand.ko insmod: ERROR: could not insert module ./cpufreq_ondemand.ko: Unknown symbol in module /var/log/messages output. 2020-05-20T09:16:37+10:00 XXXXX kernel: [687147.086168] cpufreq_ondemand: Unknown symbol gov_queue_work (err 0) 2020-05-20T09:16:37+10:00 XXXXX kernel: [687147.086187] cpufreq_ondemand: Unknown symbol cpufreq_governor_dbs (err 0) 2020-05-20T09:16:37+10:00 XXXXX kernel: [687147.086204] cpufreq_ondemand: Unknown symbol dbs_check_cpu (err 0) Ironwolf Health Management is also running ok in 0.11 (it did not in 0.10) Thanks for your efforts. DeadS

I intrend to insmod the option and then modify the cpu governers to switch to them and test their effectiveness in boosting on demand cpu frequency, then idling back down to low voltage low frequency at low demand. I'll test on both Pentium anniversary and Intel i3-9100 cpu baremetal. I see you have added it into 0.11 - thankyou - I'll test in the next couple of days and report. Cheers, DeadS

IG88, Is there a chance to have cpu-frequency scaling governor module cpufreq_ondemand.ko to allows rapid, dynamic cpu frequency change in response to demand, but reducing power when there is no demand? I have a Pentium Anniversary edition that scales from 800-4400MHz, but it is locked at either end of frequency scale by either the performance or power saving governor. I understand there is a script to make some rudimentary changes to frequency but It would be ideal if this governor was available. I'm not sure I have the necessary wherewithall to compile on myself but am happy to give that a try with some pointing at where to begin that journey. Or is the kernel in use hamstrung from supporting that cpufreq option, and I would therefore be wasting my time pursuing it? I have successfully used the std 918+ 0.8_std ds918+ - extra.lzma/extra2.lzma for loader 1.04b_mod ds918+ DSM 6.2.2 v0.8_std with hardware transcoding active and functional on Pentium Anniversary G3258 MSI B85M-E45 board, and i3-9100 with Gigabyte Z390 Gaming X motherboard. Or have I missed something completely here, and I should be using the extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.10 posted at the top of this topic more recently - I was coy because of the failure on both platforms with the syno 1.04b mod v0.8_syno but it may do away with the need for the three options completely? Thankyou for your efforts.

The details in the linked post seem to match what we have been discussing here, and editing /etc/synouser.conf appears to be the fix. Edit: Tested it with success. Login at console vi /etc/synoinfo.conf Find the line: eth0_mtu="2000" replace with: eth0_mtu="1500" save file (:wq!) Reboot Shows up in Synology Assistant again, and all services look to start correctly. The services are also available much quicker after a reboot. Now - I noticed that ONLY eth0 was set to 2000: eth3_mtu="1500" eth2_mtu="1500" eth1_mtu="1500" eth0_mtu="2000" That makes me wonder: Might an alternative solution for some to simply use a different port? At the very least - it appears that knowing that MTU is at the core of the issue should help all of us. Hi, Sorry for the long quote. There is a typo in one of my earlier posts, which has wormed its way into yours: (my bad) the file to edit is /etc/synoinfo.conf (not /etc/synouser.conf - the user account list) Also, a comment on your "Might an alternative solution for some simply to use a different port" It is a yes and no answer: Adding another ethernet port to the system will function correctly, and if that ethernet hardware port supports large frames, such as the intel server device I installed does, it will indeed support and work with large frame sizes. The problem is if you want the main services of filestation, GUI, SAMBA etc to use it, you need to convince the hardware that the new ethernet port is now eth0, as it typically will be assigned eth1, even if the onboard hardware is disabled in the BIOS (my experience anyway) - it is difficult to convince the xpenology system to use eth1 for core services. There are ways to change the port binding order so the additional card is assigned eth0, and that is the easier overall solution. However, after much work and effort on my part to get this to happen on my HP N54L, the end result was that throughput and performance were not sufficiently enhanced by achieving a 100% gigabit ethernet network 9000 mtu - it was only in the order of 5-10% at best, so ultimately the effort was not worth the time it took to do and the cost of the additional interface. Cheers, and I'm glad my original solution has been helpful to you.