ThorGroup

Members
  • Content Count

    47
  • Joined

  • Last visited

  • Days Won

    27

ThorGroup last won the day on October 3

ThorGroup had the most liked content!

Community Reputation

386 Excellent

About ThorGroup

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sadly this "requires at least one btrfs volume that only consists of synology SSDs" - there's probably a reason for that.
  2. You cannot use VMM when DSM is running as a VM itself. Technically it's possible (you can enable that option in VMWare) but the performance of VM inside of VMM will be like running Windows Vista on Pentium 133Mhz.
  3. There's a script which takes care of that. Its template is present in redpill-load repo in include/loader-ext/target_exec.sh_ - it is filled-in with by the extension manager. From the perspective of adding new drivers you should just add entries under kmods key like described in the documentation for devs and the target_exec script will take care of the rest (i.e. insmodding them etc). There are no interextension dependencies (i.e. between multiple extensions). However, when you specify multiple .ko to load in kmods key they're loaded in that order. There's a mechanism to forc
  4. With RP just add it to the synoinfo parameter in user_conf In general you can add up to 4 ports with RP now as the LKM only supports mac1-mac4 syntax. There's a newer syntax called "macs" which accepts comma-separated values but its validation was more complex and we didn't add it yet (but there's a todo in the code).
  5. So a quick up-not-to-date You guys are writing so many post and we're committed to reading all of them and responding where needed. We promised to write something more last time but few of us had slightly unpredictable life events - given the fact we usually get together physically we encounter a small delay. So, regarding the SAS issue: the sas-activator may be a flop. We tested it with SSDs and few spare HDDs which obviously weren't >2TB. It seems like the driver syno ships is ancient and while it does work it only runs using SAS2 (limit to 2TB is one of the
  6. /\ Yes, that definitely - as 3615xs has syno-built SAS modules the activator will install on 3615xs only (and the extension intentionally doesn't have a recipe for 918). However, with the LKM changes a standard unmodified mpt code should work properly.
  7. A quick update (we will write more tomorrow): the native mpt2sas driver works but it's present only on 3615xs platform. To activate it and make it working properly without any hacks just add this small extension: https://github.com/RedPill-TTG/redpill-sas-activator We also updated the kernel module to rewrite SAS => SATA ports so it should work with any off-the-shelf mpt2sas or mpt3sas driver.
  8. Quick update: Thanks to amazing reports from @WiteWulf the KP on 3615xs should be fixed now. For details see https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817 A different hard loockup seems to exist still but this shouldn't affect most of the people and judging by the last post in the issue it may not even be a bug but an over-reactive kernel protection mechanism. ==================================== We don't see a reason why not. The kernel should load it automatically. We never played with microcode updates manually but DSM isn't special h
  9. Look at the last post - somebody found a solution. It's just they hardcoded PCI ids for these We never looked at NVMe cache ourselves but if needed something can probably be done in the kernel to make it work. Depending on how their library works (i.e. does it just check for these devices and use /dev or actually use PCI commands directly [probably not]) we can maybe just fake them.
  10. Even if you forcefully insert them that's a bad idea - you can yolo things in user space but not in the kernel as userspace is guarded by the kernel and kernel is only guarded by a sparse memory managemnt unit checks The kernel space has literally no memory protection per se (ok, there are small bits here and there but this is mostly bug-catching and not protection between drivers due to performance reasons). It's a PITA that kernel modules in Linux are specific to that exact version up to the t but that's a small price to pay for a great kernel. That decision was famously made in 1991 (if so
  11. Rest of the answers starting from beginning of page 84 and ending on page 86. ======================================================================== We will love to be wrong here but to our knowledge 918+ kernel does not have SAS functionality. These symbols are present in the kernel code but guarded by "ifdef MY_ABC_HERE" which presumably depends on the model/SAS support option. Eh... it is possible to emulate that. We know how technically. We can provide these symbols virtually in RP but it will require some digging to check what they should return. Since we
  12. This post contains answers to questions up to beginning of page 84. ============================================================================ It's a holy grail to catch WHAT is actually causing that 100% spike when it happens. This is the clue of where the spinlock is taken but not released. Kernel points at influxdb and other DBs but we're sure it's not that. It's somewhere in the kernel itself. This is perfectly correct. Windows uses local time in RTC and Linux uses UTC. The behavior of windows dates back to the MSDOS days. Linux actually follows
  13. This post contains answers up to page 67. ====================================================== You should use extensions now and NOT modify any files manually. Please, do not modify the grub.cfg file. This isn't a supported method with RP and should not be used. You should add that option as an extra_cmdline in user_conf instead. That is... strange. We're adding it to our internal list as the disk test shouldn't randomly crash the pool This usually happens [on VMWare] when you use USB-boot and not SATA boot. VMWa
  14. Finally we've got some time to respond to the questions. We will try to respond to as many as possible so stay tight ======= Why there's a problem with compiling drivers when syno didn't publish kernel sources? This is going to be a separate post addressing "why you cannot randomly grab drivers and compile them" so we can link to it. Let us explain where's the problem, this applies to many questions really. There are few major issue with compiling drivers against a different sources. The three major ones are: 1) Versioning of syno kernel's is broken due
  15. We think it should be 1 driver = 1 extension. This way you install driver for your ethernet, driver for your GPU, and a driver for your USB 3 chipset. This will also let us do another cool thing down the road: provide a small image which will boot on your hardware, scan it (essentially grab vids & pids), and suggest a platform and drivers needed to make it work. VID & PID info are embedded in the drivers on linux anyway so it's easy to extract. If you pack many drivers in one package you can easily run into conflicts and load way too much. Jun's loader loaded a ton... literally all mod