Peter Suh

ARC does not show the NIC module name at all. Like RR, mshell also always displays the NIC module name. You will know right away once you install it.

Try switching to my TCRP-mshell. This is the same Redfill-based loader that was previously based on ARPL. Both loaders are compatible with each other. https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0 After switching to this loader, please tell me exactly which network module it points to. I think it's probably r8168. I also suggest this to @Flautista1988, another user who asked the same question. If there is a problem with r8168 or r8169 in the integrated module of TCRP-mshell, we will switch to the final version of the module of rr.

This complex script you are about to reference is old script. rr or tcrp-mshell is already running in the form of an addon. However, dsm cannot be installed on a system configured only with nvme. You will need at least one sata disk. You need to complete the installation starting from dsm with the help of this sata disk. Volumeization of nvme is the next step. When configuring a storage pool in Disk Manager, you will be able to use the volumetric NVME already enabled by the addon. Sent from my iPhone using Tapatalk

I hope that this time too, there will be no criticism or accusations from Taiwanese users. In the past, when DSM 6 used Jun's loader, a Taiwanese user attacked the Korean community under the premise of filing a complaint through Synology headquarters.

Who made such absurd accusations? wjz304, I hope you are not offended by those words. The effort so far has been such a waste. Is it too hard to change your mind?

It seems like there is some reason. It looks like it has been converted to hidden or private.

Will my response be too late? Is it already too late to return from pocopico's TCRP to my mshell? lol An update was just released that included a thank you note mentioning your nickname. You can check today's automatic update.

However, when I looked at the code of my menu_m.sh again, I confirmed that DS918+, included in group 4, is still coded to be activated only for 8 threads or less. https://github.com/PeterSuh-Q3/tinycore-redpill/blob/38def125c2e7072515951845d1f58f46e92f83a3/menu_m.sh#L903 In the past, I had a misunderstanding that DSM was related to kernel panic due to exceeding the number of threads, but it seems that that part was still in the code. It is now clear that there is no correlation between the number of threads and kernel panics. We will improve this part and lift the restriction. If you reboot after about 10 minutes and try to enter the MSHELL menu again, the changed version will work. Thank you for your comment.

Please tell us your CPU model. Your question doesn't say the CPU model anywhere. There are only so many CPUs with 12 cores. The i7-8700 you mentioned below has 6 cores and 12 threads. https://xpenology.com/forum/topic/13030-dsm-5x6x7x-cpu-name-cores-infomation-change-tool/?do=findComment&comment=451802 The standard for determining the Intel CPU generation related to transcoding is the presence of the movbe command. https://github.com/PeterSuh-Q3/tinycore-redpill/blob/38def125c2e7072515951845d1f58f46e92f83a3/menu_m.sh#L582 If you want to forcefully select DS918+ from the model selection list in mshell, Just select Remove Restrictions at the bottom again. You must provide accurate information so that I can give you an accurate answer.

MoetaYuko Thank you again. SA6400, which stabilized transcoding, was officially released to TCRP-mshell a while ago. I have completed verification on the 4th, 11th, and 13th generations of Intel, and will conduct additional verification on other generation CPUs. Is this possible for Ryzen GPU as well? I wonder.

[NOTICE] TCRP-MSHELL SA6400 i915 transcoding stabilization notice A few days ago, when updating SA6400-7.2.1 U3, there was a fatal error when automatically patching the RAM disk, so I fixed it. There was one more error left. When automatic updates occur, not only ramdisk patches but also kernel patches occur. The kernel patch script for kernel 5 was in the friend tools folder developed by @pocopico. This script was not complete. So there was a problem that resulted in a kernel panic. Stabilize the same by referring to ARPL's patch script. Today I upgraded the FRIEND kernel to version 0.0.9i. Currently, this version is verified by @MoetaYuko for Intel 4th, 11th, and 13th generations (a stable version that replaced the existing @jimmmmm version) It has been replaced with the i915.ko file. You can apply it by rebuilding the TCRP-mshell loader. It seems that all processors from the 4th generation of Intel that were previously capable of transcoding will be capable of transcoding. I think users should verify it one by one and give feedback. Status of automatic update up to SA6400-7.2.1 U3 and presence of /dev/dri folder This confirms the stable loading status of the i915 module. I haven't been able to check the HW transcoding message because I don't have a plex pass yet, but if you have a pass, (HW) will likely appear. I confirmed that even with SW transcoding, it played well while maintaining a CPU load of 7%. No additional activation processing for transcoding, such as installing AME, etc. was done. The serial number is also a virtual serial number randomly generated by TCRP.

The reason why the CPU speed appears low is because the CPU frequency scalable add-on is running. This add-on lowers the frequency during idle timing to save power. In the opposite case, when the CPU starts operating, the frequency increases and goes up to the maximum allowable value. A quick search of the forums will find a q/a on this issue. However, one bug is that, as you captured, only the minimum speed at idle is displayed and the changing increased speed cannot be displayed. Did you run into problems if you didn't set thread limits on your Xeon? If there are no particular problems, the performance of Xeon, which can utilize all threads, is likely to be superior. Sent from my iPhone using Tapatalk

After comparing the error log you provided with the information from lspci, It seems that the currently used DDSML mode does not cover the VID+PID of the 12th/13th generation devices. I will improve the device compatibility of DDSML by reinforcing the modules.alias.4.json file. I suggest switching to EUDEV, which uses dynamic mapping, instead of DDSML, which uses static module mapping. It exists as the first menu in the TCRP loader build menu. After switching to DDSML -> EUDEV, rebuild the loader and check again whether the NIC or SATA controller is recognized. If the problem still repeats, we will guide you again on how to check the error log. The case of EUDEV may be slightly different.

The process of finding and loading two ixgbe modules related to the 10g nic appears in the log. We need to find a reason why the rest of the NICs can't even try. How many physical NIC ports are there? And the RAID controller and SATA controller seem to be special. I can't find the related expansion module. What models do you know of these two controllers? Please let me know the results of running the command below in tinycore linux. lspci -tvnnq

Models that inevitably require modification of libsynonvme.so.1 and are limited to only 1 or 2 mountable nmves are also clearly shown in rr's script that references my nvme-cache. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/nvme-cache/src/install-nvme-cache.sh https://github.com/wjz304/rr-addons/blob/main/nvmecache/all/usr/bin/nvmecache.sh DS918+ RS1619xs+ DS419+ DS1019+ DS719+ DS1621xs+ Limited to the 6 models above. If you look at the contents of the file with an actual hex editor, this model name and the PCIE address of the specified genuine product are recorded. Other models depend on device tree configuration or configuration in the extensionPorts file. Adjust to recognize nvme cache in these three types. 1823xs+, DS1821+ and DS1621+ are device tree based models, so the libsynonvme.so.1 file is not involved. If you consider it complexly rather than simply distinguishing it, confusion can arise.