Jump to content
XPEnology Community

ThorGroup

Member
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    27

ThorGroup last won the day on October 3 2021

ThorGroup had the most liked content!

Recent Profile Visitors

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

ThorGroup's Achievements

Junior Member

Junior Member (2/7)

394

Reputation

  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 force extensions load order (extensions key in user_conf as described in dev docs for extensions) as a stop-gap. This should be rare however as drivers loading is for the most part asynchronous in linux anyway. Spot on: dependency graph is needed for that. It would TECHNICALLY be possible in bash but oh boy... that's insane in a very wrong way Being serious we're planning and preparing for a rewrite of extension manager so that it can support dependencies properly. The current solution is a good-enough PoC to see if the idea will work. We designed it and brainstormed through multiple people to give the community a PoC which is functional (this is probably close to a 10th iteration of the design of extensions itself) but maybe not with all bells and whistles right away. From the perspective of time choosing bash on principle of "it doesn't require installation" was a mistake.
  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 symptoms). Don't we all love that ancient kernel? Probably on systems with mpt3sas the situation isn't a problem. As to the native SAS support and how it works: in short it's useless. The SAS support in syno is tied to just a few hardcoded models. Most of them support only external ports (via eboxes). Some, like in a few FS* products support internal ports. Unfortunately, this is completely useless as the OS checks for custom firmware, board names, responses etc. Is it possible to emulate that? Yes. Does it make sense? In our opinion not at all. With the community-provided drivers we can all be fully independent of the syno-provided .ko in the image. As the LKM supports SAS-to-SATA emulation for the purpose of syno APIs thinking it's a "SATA" device further investment into true SAS doesn't really make sense. To be clear here: there's no loss of functionality or anything. Many things in the kernel actually use the "SATA" type. It seems like syno intended it to be a true SATA but down the road changed it to really mean "a normal SCSI-based disk". The reason why syno separates real SAS controllers is to offer .... hmm, a lot of hacks over their firmware and timing issues with LSI controllers. So in short emulating a true SAS type in syno will give us no benefits. Saying this we also, very cautiously, should probably make a recommendation: for anyone using a standard array of disks of 4-8 it's probably a better choice to go with a Marvell-based chip which works natively without drivers (and which syno uses as well). For bigger installations LSIs are still preferred (as they're cheap, work with low-cost used SAS drives, save on cabling etc etc). =============================================== And now a massive response stream to all questions That pesky /dev/sda may actually be a bug in the syno kernel. According to the IdxMap it should NOT present itself at the first spot grrr... we set it to map controller 1 to like 20 and it still used the first disk (and only the first) at /dev/sda. There may be a way to use remap of ports (another feature which syno uses extensively on their boards) to move it. It would actually explain why syno uses a long string of remaps (comically long, like 30-entries-long) instead of a map on some of their boards... as map seems to not work properly. We will play with it. Can you create an issue in the redpill-lkm repo, so we don't lose track of that? It may also be a problem with magic index shifting... it looks like Jun's loader may have been fixing a bug in syno's remap code. Yup... exactly the problem as described at the beginning of the post. It was too easy to simply load their drivers. This lead us to write that summary on the top - it looks like anyone dependent on the LSI card will need to use a 3rd-party driver as the syno one is ancient and only uses SAS2 (and thus the limit). For us, to be honest, the main drive towards DVA are the native nVidia drivers. While they surely can be installed on other DS it would be just simply easier to install them from the pkg manager and call it a day. As for the surveillance station stuff (and photo station and similar) patching binaries isn't that good of an approach. This is because they're checksumed. Maybe not these but others are. In general changing any of the signed syno files in the OS is a slippery slope - it's better to make sure the OS thinks it's a real motherboard rather than modify the system to not check something. The more things we can emulate in the kernel the better as updates are unlikely to break them (as they would break real hardware as well). See, the issue is while we can surely control a fan from PMU it's completely different on every motherboard. Like they never did put any standards in - guys from lm-sensors are pulling their hairs out to handle all that. We don't have a good idea just yet how to make this good so that everyone can just define their way of controlling the fans but this is something we have on the list as "todo" (albeit low priority as usually people just set their CPU and case fans from the bios, with newer motherboards you can even upload/set fan curves in the BIOS/UEFI itself). Yes we do (even if slowly!) GH is much easier to deal with simply because we can split multiple problems into "buckets" and easily ping people with that particular problem. Forum isn't really a good tool for that (but fantastic for a general discussion and support questions!). .ko can be included using RP extension. You can find examples and documentation in the redpill-load repo. It will simply load .ko you list automatically. Built-in card in gen8 should work with these drivers. To give you more context for the "SATA" thing: it's stupid. It looks like a huge legacy part in the syno code. As we wrote above "SATA" is used in the syno kernel additions as kind of "anything SCSI-based which is not a USB drive, not iSCSI and not cache-NVMe". There's no performance penalty or anything. In face they themselves treat VirtIO as "SATA". Ultimately, the kernel doesn't care about their types at all. These are only there to guide the OS what to do and not do with these drives (e.g. don't make swap partition or create OS partitions on iSCSI). It's like with VirtIO ethernet driver: DSM will show a warning that the network is 10/100Mb [as it sees it as "unknown"] but will happily push gigabits of traffic through it. As for the general advice if you use QEmu-based systems use Q35 unless you have a good damn reason for older chipset (e.g. Windows 98 VM or something along these lines). They keep the i440fx as the default as it's most compatible but in general Q35 is the one you should use for any modern OSes. As for NVMe SSD: these are well... PCI-Ex devices. They go through a slightly different pathway. But again: kernel doesn't care really. There are mods for the OS to see non-syno drives as valid SSD cache. However, with some kernel tweaks we can probably get rid of these modifications (hint: if there isn't a GH ticker it will be appreciate in the redpill-lkm repository, so we have this on our radar). pinging @haydibe here. The loader itself doesn't care [now] but probably the container config has some assumption somewhere. You can leave them, you can even set them to DEAD and BEEF - it will not cause any problems but a warning message during boot When they're set but not needed they're only validated to the point of "is this a hex number". [note to ANYONE doing supportsas=yes] You shouldn't really do that. This activates syno-specific SAS support which will break a lot of things. This flag is horribly misleading and used in aaaaa looot of syno code. This is way more than just loading the driver. This is more of a "activate our hacks for broken LSI firmware we flashed ... and do these totally not-SAS things on this controller ... and when you are at that can you maybe also tell the controller to take over controlling some of the leds ... oh, and load the driver". So folks, really, don't touch that option with a long pole - it's a trap. It would only be useful if full ebox emulation was present. We're working with haydibe on integrating the container build into the redpill-repo itself It just spun as a very cool project in this thread and it turns out it's actually great. Adding to what WiteWulf said here: yes, it's because of the kernel changes in ~v6. From the Linux perspective it doesn't care where messages are sent - every printk() goes to /dev/console. Something has to actually handle the /dev/console however. This needs a driver. To see messages on the screen you need to have some sort of framebuffer/vga-like driver. By default every desktop distro will obviously include vga driver in the kernel, but in embedded systems it's rare to include it. Syno simply stripped it from the kernel build. GRUB renders the text and passes control to the kernel and kernel decides to not reset the screen nor display anything on it. It's as simple as that, that's why what GRUB leaves never disappears from the screen We didn't try but probably if you use nV GPU for boot and then load nV drivers for transcoding the screen may turn simply black (or perhaps even disable the connected display?). 918+ is out of question for 1240v2 as it doesn't have MOVBE instruction and 4.4 as built by syno requires it. Even if it "boots" things will start randomly crashing. The 3615 speed shouldn't be limited by the platform itself. With such speeds you may need to tweak kernel networking but this is honestly the same on syno as for any other Linux box. We want to add 3617 but that hotplug issue is that annoying showstopper. As we were busy we didn't debug it much beyond what's said on GH. It's probably something stupidly small... It's more difficult because you're editing the image and making changes which will explode in the future. There's a reason why we automated that hard stuff into extensions Don't you have COMs inverted in the RBSU? Gen8 is such an amazing server but iLO... iLO was written past the Bellmer's curve (e.g. to enable PCI-passthrough you need RMRR hacks because HP decided to mess with it against the ACPI specs). If it detects synoboot it's all good and it means it detected the stick properly. In other words your vid/pid combo is correct. This is something new with these want_idx. Can you add it as an issue in the redpill-lkm repo? In general you shouldn't use the VirtIO SCSI Single. This is a completely different issue related to security checks in the DSM photo itself. If you google search within xpenology.com you will find many mentions and discussion on patching that in the system. In short: a real S/N is needed to make validation happy without DSM patching. Wait... are you saying this doesn't require the paid license but just a config edit?! Also: there's a new bash tool in the loader repo called "always-telnet" - you may find it useful with working with VMWare serial ports. Migrate it to Proxmox, it will be way less problematic,join the dark side ;] ESXi + gen8 is an issue in a lot of places. VMWare dropped support for newer versions, there are weird memory leaks in newer versions etc. It's REALLY not a good platform for ESXi (not that we're biased against ESXi in general but that's another story ;)). ...if only Gen8 had 32GB RAM support. Oh, wait, it can support it but Intel forced HP to disable it. We use and recommend Proxmox [not just for RP] - open source, not limited in features, fast, supported and doesn't cut out hardware. The only problem on gen8 is PCI-Ex passthru due to RMRR but if you search on GitHub there are patches. Exactly that patch - we use this ourselves for long time and it's rock stable. ESXi does essentially the same thing - just ignore bogus RMRR from HP. Ok, you surprised us here! Never heard of that before. However, we need to check how full vmtools do that. In the [red hot] queue. At this point, as many people tested it, we can just merge it but we really want to look at the kernel in a disassembler and see if nothing changed and the automatic path is correct. We try to make sure what we publish is well tested Sadly Intel artificially limited that with efuses... like ECC on i5 and i7 and many other things. Extensions itself don't depend on the software version per-se. You can make an extension compatible with yet-unreleased version as during installation we query for the version which is being built and we don't care where the extension or version is coming from. The power of open-source. Really the best HW transcoding with H265 support is an nVidia GPU. Something cheap and easy to get like P400. However, syno doesn't ship drivers for nV on systems other than their "AI" powered boxes for cameras. Great usecase for transcoding: watching movies on Oculus Quest in bed Also, cheap streaming sticks often freeze or reboot on higher quality local rips of BRs. Some SDR TVs also reallllllyy don't like HDR content. You probably installed too many drivers or found a bug causing a loop somewhere. You shouldn't really go above the space allocated (~50MB) as this is plenty for drivers you need on a single platform. Jun's loader modify the values if we remember correctly. In general, we just pass them to the kernel as-is. There's a validation in the kernel itself but we don't do a validation during image build due to painfuliness of coding such things in bash. In such cases just look at dmesg output when RP loads - it will say exactly what went wrong. The stupid thing is it should NOT be. Synoboot never appear as sda, it just looks like there's a bug in the syno code and despite them taking a different symbol (i.e. synoboot and not sdX) the counter for "used" letters is still incremented and not affected by their mapping. We need to find a good place to plug into that and fix it. It is used but doesn't always work as it should. You guys can also try playing with "sata_remap" or "ahci_remap" options. Their syntax is like: ahci_remap="0>16:16>0:1>17:17>1" and continues. Syno uses this a lot to rearrange ports. Don't forget about the "..." around that map. In JSON you have to escape it like \" Yup, exactly what we wrote above This isn't really RPs variable. These are remaps in the syno kernel. All of these "magic" options are defined in kernel/syno_bootargs.c and quite easy to understand. Sorry to be blunt but what you're doing in this script is very stupid (in a sense of code, not you as the author :)) and dangerous. You're adding compilation options which we're almost sure you have no idea about. You've got an error with the new GCC about the PIE relocation/ASLR so you just changed the makefile for the LKM to use -fno-pie... sure, go for it! That's definitely why that error was stopping the build process so that -fno-pie can be simply added to the build line (/s). We're strongly recommending a read of a post we put on page 55 which discusses some of the GCC stuff (which was discussed many times in this thread before). GCC isn't like Python or V8 - the version REALLY matters. Linux v3 will not build with >=5 for example. There are good reasons why kernel developers are extremely careful and have patches applied per GCC version in the code. The fact some code compiles is just at best 50% of the success with GCC. Additionally, you're going against everything we recommended here. Really, this script is a collection of all "what not to do" we warned against in this thread: don't compile LKM or kernel bootstrap with GCC >4.9.2 (yet the script just YOLOs it) don't install random drivers loading 101 unneeded ones (and that's why we developed the extensions at all, but the script just adds a collection of drivers even if most people don't need them) configure user_config for yourself which you gonna keep for long time and which is semantically valid (yet the script just obliterates it with sed, not even a jq which was installed) read the docs & configurable options in commands (yet the script just does a forceful "mv" instead just using an option already provided for that) and as a desert: it will fail if your path has spaces in it. To not be just grumpy and complain we will make a suggestion: utilize a docker image by @haydibe which works great and does things safely. It soon will be merged into the main repository as well. Obviously, as the project is open-source and on top of that a full-blown GNU, we cannot stop you from using it. However trust us on that: we collectively wasted long weeks on dealing with pesky bugs where things weren't compiled exactly right and in a proper environment. See sad update on the top. Also, you should NOT use supportsas=yes as it does WAY more than just "adding SAS support". There are even more things associated with it (e.g. SASModel kernel boot option, which you shouldn't use either ;)). We said that before but as a reminder if someone missed: don't add supportsas=yes. This doesn't do what it says it does sadly. Don't edit these files manually. You can set any options in these files by adding "synoinfo" section to your user_conf. There's an example in the repo. Any options you set will take priority over default ones. The automatic code takes care about figuring out which options to remove/add/modify and to do it in 4 different files across 2 environments. You should not use that script at all. Use the container recipes provided here by haybide.
  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 here. Do you have two images where one is working on Q6600 and one is not? One of our devs may even have Q6600 on P5B Deluxe somewhere but it's a very old platform and we don't know if it still works after so many years That sounds REALLY good actually! We may try for a test installation observing 3D printers. We wonder how they actually detect what's a real S/N<=>MAC combo and what's not. We doubt it's calling to the outside API... because if it's that simple adding an emulation is probably pretty trivial. It's probably more a checksum than anything. The DVA support is really held mostly by the S/N generation. Despite our efforts of searching around we weren't able to find how previous S/N generators were written (i.e. based on what information). FYI: no packages from v6 will really work on v7 without modification. They changed a lot, actually modernizing the package manager. Even simple things like Plex needed a new package for v7. A real-life DLC.... the thing is what's the point of paying for a SERVER if you don't have any OOB management? That's probably why they release Gen10+ so quickly after Gen10 as people were still buying Gen 8. Yes, the final goal is to have the default be just the "dev.ext_name" installation but with always-available option to use manual URL. The repo has a simple format for now as we don't have a plan HOW it will be structured. However, we are definitely want to keep everything static to avoid having any active servers (more like apt/dpkg and unlike NPM). Currently, the extension names are only mean to force the order of loading. 99% of the users will never use that key. We're currently messaging with @haydibe to see how to make extensions interface nice with containers. Remember that this method will RESET this setting when you update RP in the future. That's why we say to add this to the user_conf For testing it's easier to press "e" in the GRUB menu to edit the entry, add params which you want to test, and then press Ctrl+x to boot modified entry. Are you sure you don't have some compatibility mode set in the BIOS? As 32bit has a limit to 4GB and there were hacks to extend that for OSes like Windows XP. Look under things like "PAE", "Physical Address Extension" or a selector for OS type (some BIOSes have selector like DOS/Legacy/Other - usually picking Other disables all magic wizardy hacks). RP does not need [or shouldn't] the Jun's hack to "hide" the loader as the 13th disk as we set synoboot in kernel and that disk is never visible to the DSM UI. So calculate everything as if that disk was never there. Your first disk can certainly land at "/dev/sda" (in Jun's loader some platforms could never use sda but started from sdb). Depending on the platform the boot from SAS should work (typing from memory here). In general, we try to be pretty flexible as to what "SATA boot" is and make it "anything SCSI matching the size except USB". If you're running 3615xs there's also SasIdxMap <frantically checking housing prices in Romania> Correction: you can do pretty much what you want on the internet from RU as long as you do it to countries which aren't Russia. Not getting political but there's a reason why a lot C&C servers for malware are ran in Russia. Gen8 has a broadcomm card. The driver, if someone compiles it, should work. The KP should be fixed for the most part on 3615xs - see GH issue for details: https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817 As for the ethernet use VirtIO if you can [i.e. not on VMWare] as it's a paravirtualized interface [=low overhead/faster] and e1000e otherwise (doesn't need drivers). e1000 is a different card.
  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 someone's interested google for Linux vs Minix and now-legendary exchange between Linus T and Minix author - it could be a hollywood movie). This is why RedPill extensions system is VERY specific to the versions of modules so nobody accidentally even try loading wrong driver's version as this is much more dangerous on Linux than on Windows or macOS. Drivers on Linux are literally running on the same privilege level as the kernel itself. On macOS more and more are in userspace or are at least partially isolated. This is why nobody should experiment with e.g. SAS drivers on a drive with data which they care about [unless tested by many and confirmed working properly].
  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 don't care about REAL SAS support (as syno-supplied controllers have a custom firmware anyway) we can just shim them. However, we see some success from @pocopico and @Orphée here so we will... wait for an extension maybe? THAT WE CAN FIX! We can add that symbol if needed. We saw Jun replacing that symbol but we had no idea why. Famous last words: that should be easy. 36xx is rocky with v7 overall. We've lost two pools on a real DS - a complete ext4 crash. Surprisingly btrfs is more stable this time, but someone reported here data loss with btrfs as well. However, there's a shell hack to forcefully just load USB device kernel modules. It's just they're through with supporting that probably. Yes, you are correct. We were thinking about that as well but decided against dividing drivers. There's no harm in loading all of them in pre-boot. On some of our servers (unrelated to DSM) we have 10Gb/s networking in initramfs to boot from them. We couldn't find an argument for splitting drivers to core and non-core besides size. Since loading a ramdisk layer seem to work up to ~430MB we don't think we will hit that limit any time soon. We don't copy modules like Jun did - we just load them from memory to different memory. You don't need to unload and reload them on runtime. On hot-plug systems you may do that but syno doesn't do that themselves either and essentially loads drivers based on configs in preboot. If the .ko is shipped within the PAT go for it and load it - at least we know it's compilled properly. It may still have missing symbols but see beginning of this post. ...and this is exactly why we run a Proxmox. A VM for DSM + a VM for stuff like HA, NUT, or Avahi. Trying to put it on a NAS is already tricky but I'm sure it will piss off a lot of real DS users as for most the NAS is their only server. Teeechincaaaaally speaking as long as the NUC is able to BOOT from the USB3.0 the RP shouldn't have a problem interacting with it as it loads all drivers, including USB3. The only issue may be the driver for the controller itself - if it's not supported by the native Linux xHCI driver you will need to add it as an extension. See the roadmap [few posts from this account back] We want to fix the SAS thing [which as we see guys are already figuring out here] and integrate container build into the load repo - then an instruction will be posted. We also want to solve that annoying crash/lockup issue with 3615xs as we cannot call it stable or even beta if every database crashes it within minutes-hours. Yes, we're trying - the biggest issue, which is slightly funny, is that we have hard time reliably crashing it. That isn't a problem - you just need to set SataDisk... params properly to move disks and it will fix itself. See: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352 With all due respect: looking at this thread we see many people don't know what to edit and what to put (e.g. randomly stuffing sata_pcislot or doing replacements of hwmon configuration parameters). Doing a quick "e" in grub and adding something which YOU know what it does is obviously something we do as well, however advising people to open images and edit grub.cfg isn't wise. A prime example are disk/controllers settings: you can spend days trying random values found all over the forum OR spend 15-20 minutes understanding what these values do and configure them per your system. Many people don't realize some values are specific to their own config. Additional issue, which we repeated multiple times here, is sharing the loader image. It's a VERY bad idea. Read the first post in this thread: we didn't start RP. The original thread is gone, original repos are gone, ... there's a reason for that and it's not one you want to step into. Trust us on that: sharing precompiled images is a very bad idea. The kernel and modules are open source and under GPL - you can do literally whatever you want with them. However, the final image contains proprietary syno modules and their userland tools which are as far from open source as possible. Connect the dots here why we say to not share the full image and went into a huge effort of creating tools to build the image. It would be much easier to drop an .img or .vmdk and call it a day but the times changed. ======================================================================== Yay! We're done - it took some time Now we need to think about a great PM from @haydibe ^^
  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 ACPI specs. This is normal to see when you run any Linux on a PC as ancient RTC spec has no way of setting timezone. Just a small quirk - if you're not dualbooting windows you can just ignore that. That is a very important clue - it may be something related to vUART driver we wrote as it uses a LOT of spinlocks. Do you mean auto power on? This feature is not supported - we didn't emulate it. Do you rely on it? Do you use it? We can add it - as we explained in one of the updates we didn't bother adding it as it isn't easy and it's broken on many motherboards anyway. If you will like to see that feature added please open issue on GitHub in the redpill-lkm repository. Please don't share the final image. Especially if the link points to any of your servers - the final image contains copyrighted material and may get you into troubles. We (and @WiteWulf below) explained it few times here already. As for the 3617xs see the "mysteries.md" file in dsm-research repo on our GH - we aren't actively working on it right now for reasons described there. We probably come back to it when we have some spare time. Ryzens + v3.10 is usually fixable by injecting newer microcode But running a full ryzen bare metal with 3515xs.... why, just why? That's a good addition actually - it's simple to add that in GRUB Can you add an issue in the redpill-load repo maybe? That isn't actually related to RP - you need to see on your router where the traffic is going, or try tcpdump on DSM itself to see where it sends/receives data. Yes, when we add 3617xs support you can just upgrade in-place. It will work like moving disks from one DS to another. Boot shouldn't take that long - it should take under a minute really. kvm64 has many instructions disabled. Ideally when you can you should use host every time for any VM (no matter what it is in general if you're running something modern). We didn't look into that update but most likely just the flash updater has to be blocked overall (we blocked it based on other things but we didn't see an actual PAT to test it). Running it may just crash the machine. This is a great point actually. Even VMWare discourages from passing disks itself (and SMART is just one of many issues with passing a disk). Passing disks is bad on any hypervisor we saw as SMART is not proxied. It could be but there are security issues with that so no hypervisor does that. Please, REMOVE supportsystemtemperature & supportsystemwarning. Actually to properly do that (since using that hack you actually damaged your OS) you should change them to "yes", boot once, and then remove them from your config. We are jealous ^^ Eastern Europe? You can now pack it into an extension. Let us know in case of problems. You can now use an extension and RP will load it automatically on boot. Syno doesn't have depmod and use forceful/static insmod rather than intelligent modprobe. Whoever made that.... has no idea about the loader. We're sorry for harsh words but you CANNOT - ABSOLUTELY CANNOT - SAY that a single bootable image supports "6.2.4 to 7.0.1". Each version requires a static kernel patch. You can boot with an incompatible kernel - sure - but this is a disaster and nobody should ever do that. Never ever. You should NOT edit grub.cfg. If you want to change parameters you should use user_conf.json We love that! We will definitely look at compressing images on v7 as it's annoying they're not. Now since the extensions are supported you can inject drivers See the details in our last announcment post (scroll up - it should glow green as "popular"). As we wrote in the post above - the auto power on is not supported by design as we got frustrated that out of 6 motherboards we tested it worked only on one and only with max 2 scheduled events. If you rely on it we can add it - please add an issue to redpill-lkm repo. It will come with a disclaimer "it may not work" as auto-poweron on PCs is very finicky and we cannot do more than ask the BIOS (or rather the RTC chip) "pretty please set the schedule". Actually the update shouldn't override files on synoboot1 (as these are treate more like a ROM on real devices and serve as a backup boot in case the synoboot2 fails), but attempting to boot the kernel from version A with OS files from version B will not end well... ever. This is sadly coincidental, as we didn't touch locks there We're still debugging that. The most annoying thing is that it actually doesn't crash very reliably on our gen 8s. It does but rarely. You shouldn't use just any random MAC. There's many octets you can change but some have special meaning - just let ESXi (or whatever you use) generate it for you and put it in the user_conf. If you're just starting with virtualization we recommend Proxmox instead of ESXi for many reasons. TECHNICALLY yes, but in practice we want to make it in-place. So you just run a docker command on the DSM itself which will build everything and instead of spitting out the image it will just update the /dev/synoboot in-place. At which point you can just update from the DSM panel and reboot. We didn't develop an auto-patching-on-boot as if you use any custom drivers you have to change them anyway and things get complicated quickly. Seeing as syno doesn't release updates very often (ok, maybe except broken v7 releases) it's not that big of a problem. Our priority is on stability (yes, we know how it sounds with the crashing 3615xs now but trust us ;)) rather than having a thread where users cry that they updated, rebooted and now the system is not working at all. That shouldn't be possible. In the hackintosh community it works similarly if you do everything right: you cannot accidentally update to an incompatible release. Check what they did rebrand Of course if you use their official NIC it will work but there are many cards which are just supported. The easiest way is to check which chipset their NICs use and find a generic from Intel/HP/Dell/etc. Sometimes Intel one will run you $150 but if you search by chipset you will find the same things branded with HP for $50. Like we have a lot of HP 360T deployed as they're solid Intel 2x1G NICs and are laughably cheap (like $15). Did you built it with old GCC? (like 4.9-old) You can't build modules for old kernels using new GCCs. Pro tip: NC360T works in x1 slot You can either order a raiser from x1 to x4 or use a saw (no, we're not joking). http://www.invisiblerobot.com/pcie_x1/ - you're trying this at your own risk but it does work and with 2x1Gb it shouldn't bottleneck. That warning is [sadly] normal as we don't have sources for the kernel. That warning is there as we're using a struct which is... well... HOPEFULLY correct If it's not we may be in trouble. There's a slim chance it's not but who know what they tinkered with? It's working, but we are scared of the SATA boot on 918+ because of that. As we [hope] most of us are adults here there may have been few too many adult beverages when someone said "but guys guys listen... what if we EMULATE USB WITH SATA!" ... and as crazy as it sounds this is how the SATA boot was born on 918+ but the warning is there to scare away anyone from trying something like that with another crazy idea. It's just the toolkit headers don't come with full headers but only public ones (which is EXACTLY to prevent module authors from exploiting private API of the kernel). The VID/PID with SATA boot is completely irrelevant. We just flat-out ignore it completely. There's even a warning in dmesg (which can be safely ignored, it's just more for analyzing logs) that these parameters were completely ignored. Something went bad... really really REALLY bad. But this is most likely the same annoying bug as with crashing influxdb and CPU soft lockup. See https://github.com/RedPill-TTG/redpill-lkm/issues/21 But also as @WiteWulf suggested DON'T use a single vCPU with one vCORE. Versions of DSM with >1 core assume in many places that the system has at least 2 cores. Don't ask us to comment on that Also you need at least 600MB ram (even if it technically runs on 512). So many people praise Surveillance Station... maybe we should actually try it. Slightly OT but if you're using it (or anyone else): do you recommend it? We mostly use Ubiquity gear for that and it's ... OK, but not really stable. Didn't they remove iLO from Gen10 and added as a separate purchase in Gen10+? That temperature isn't real. We wrote about this in a previous post. Currently we sweep-emulate fake temps and voltages inside of the kernel module (to satisfy HWMON subsystem). What we have on our todo list is adding real CPU temp - other params cannot really be read natively as there's no single standard which one is which sensor (you read sensors and which sensor is what depends on mobo/bios/configuration of the bios/boot mode/etc). Temp is fake, cpu frequency is real, cpu model is.... whatever synology thinks it is The cpu model is just cosmetics, doesn't really affect anything - just a pretty thing to show on spec sheet (and its not read from the real microcode but guessed by mfgBIOS based on different parameters). We randomize temperature and then hover around it. Don't edit manually the grub.cfg - add it to the user_conf in the extra_cmdline section. Be careful with setting multiple vCPUs - they tinkered with number of CPUs (not cores) in the kernel. It cannot be trusted to work properly on systems which ship with single CPU (i.e. all but some rack stations? do they even ship with 2 CPUs?). Yes, that's a quirk of the syno code itself - it doesn't care about lower/upper case but does care about : in the MAC. During boot RP actually errors-out with that on serial console as it verifies the MAC a bit (just length really). Don't add random parameters like that. First of all, you should NOT edit grub.cfg but put your params in user_conf.json instead. Second for the disk parametrs see this great explanation: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352 Third: do NOT add sata_uid or sata_pcislot - these are Jun's custom parameters which were never implemented but were left there. The difference is Jun's loader was removing them from cmdline so that DSM cannot see them - RP does not as we never used them. Making them visible to DSM shows the DSM clearly it's running on non-official hardware. Can you make extensions out of those? So it seems PostgreSQL is the best for triggering that crash (DSM index, plex, music - all use PgSQL). Noted This is unrelated to syno - this is the kernel yelling at the manufacturer of your USB device which has no S/N (any USB device should have it... a lot don't ignore the USB spec). This will not break anything - it's just the kernel being pedantic. It's just semantics - SAS command set uses SCSI like SATA with some differences like how SMART is handled. The situation is similar with PCI and PCI-Express. The physical interface matters to the controller, to the OS it's abstracted under a single SCSI interface (yes, the same ancient SCSI) no matter if the physical disk is a SAS or SATA one. There are even breakout boards for SATA drivers allowing for dual-channel SAS connection (for redudancy). SAS and 918+ isn't something which will ever work natively. However, if we force DSM to see SAS as SATA.... that's a different story. Do NOT edit grub.cfg - edit user_conf.json We knew someone will catch our quick final tests with public repos They were public before the post for probably total of 10 minutes. See ============================================================================ This post reached 50 quotes - we will continue in the next one.
  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. VMWare doens't support USB boot unless you use a physical USB stick connected to a USB-2.0 port [as booting from 3.0 is not exactly working]. The issue is actually both ESXi and other VMWare products internally support both. However, newer ESXis don't like just flat VMDKs for some reason. Even generating the descriptor it fails to boot half of the time when the image is not "blessed" by the VMWare's own tool. FYI image will always be 128MB (unless we change the base) - you will only see a real change in size when you compress it with e.g. ZIP so it removes all the empty space in it. Gen 8 is on our list to figure out fully as we have quite a few of them FYI: That is slightly playing with fire. Internally they assume (at leas in v6) that the disk will be 3 characters in a form of "sdX" unless we missed something. The fact it shows up in the GUI doesn't mean it works correctly. There is probably a reason why they don't sell units with >26 internal drive bays That randomly popsup even on real hardware. Sometimes threads of scemd crash/freeze and it tries for some time to recover them before killing and restarting. Nothing to worry about unless it happens constantly. Correction: it's not the Linux being confused but the mfgBIOS code. Linux doesn't care - this is why the network may appear to work. But syno services do care. Instead of using the API they went around it so when the MACs aren't in order some things try to use the normal API where others use the syno API... and this is what happens. We usually just boot with one random MAC defined and just "ip a" quickly to see how the kernel sees ethernets in that particular system. Any time you see gpioerrors on 918+ it means the module didn't load at all. You should check dmesg. Now the problem shouldn't really exist as if RP fails to load it will deliberately panic the kernel with a detailed log to avoid such "wtf" situations. FYI this seems like the bug reported for the kernel crashing: https://github.com/RedPill-TTG/redpill-lkm/issues/21 That is extremely hard to debug as kernel lockup is essentially "welp, someone tried to take a spinlock but there's another spinlock running". The fact we cannot compile our own kernel, due to broken sources from syno, makes debugging this issue a nightmare. Take a drink for D3x - she's trying to find the issue for some time now. Preliminary testing shows that may not even be the issue with RP but with the kernel mods by syno itself. Oh yes, iommu... that is sometimes tricky. In general IOMMU should be disabled unless you use VMs as it causes more problems even on standard Linux distros. Intel MMU implementation is very... very.... hacky. They improved a lot since 9th gen but older ones are often unstable. A lot of times installing a microcode update helps. ...and now we have extensions We hope you like it as we see you play with drivers a lot. That should be fixed now as @pocopico mentioned. We dialed down these debug messages. They're actually perfectly fine. That external storage warning is not and there's an issue on GH for this one as we recall correctly. It should be the same as this one: https://github.com/RedPill-TTG/redpill-load/issues/30 See We have a limited set of hands and try to prioritize getting as many things correctly as we can on the current version. Adding v7.0.1 when we have v7.0 is trivial but adds another thing to test and potentially debug the issues if any. As we described in the roadmap we want to merge all new software releases. Going further we will merge them much faster when the major load we have is a new release and not 42 different things to check and patch + new version We try to make this about quality and thus we don't blindly merge new releases either - we check every single kernel manually to see if nothing actually changed and don't just use autogenerated patches (as you know, any time you code something - like a generator - you will never trust it as an author ;)). See https://github.com/RedPill-TTG/redpill-lkm/issues/21 We know it's an issue create by you but we're leaving a link to have trace here: https://github.com/RedPill-TTG/redpill-load/issues/30 Thank you for creating this is an issue so we can track it easier Now you can use extensions instead of tinkering with rd. Do you feel comfortable publishing these modules as extensions? Also, there's an issue for the telnet. We think it can be made an extension as well: https://github.com/RedPill-TTG/redpill-load/issues/31= https://github.com/RedPill-TTG/redpill-lkm/issues/21 v7 is a huge beta... on 36**xs we will call it an alpha., and we're not talking about RP+v7 but overall v7. In our production environment no [real syno] devices are running v7 as the real gain is minuscule in comparison to alllll the bugs (some potentially causing data loss) which are there. Give it 6-8 months at least. The issue here is that if we recommend to users to use random forks where everyone changes random things it will be really impossible to support in any way from our end. This will end up with "oh, I used this fork mixed with that which changed 10 scripts and it's broken - why?" Not that we want to discourage forking in any way but we already see a flow of issue from forks where users are confused and create issue that modules are not being copied where this was hacked around in one of the forks. Thank you for stripping the custom forks from the image - we think the forks are great for tinkering by developers but when users try to use them without any knowledge of what they really it's a recipe for a fire in a forest. This was nicely shown by the quick supportsystemtemperature hack which breaks more than it fixes. We already see people putting toolchain version in their signatures which shows us they don't understand that the actual toolchain doesn't affect how the loader works and that it's only used to create the build environment. "Generating completely fake SMART" means that DSM asked for SMART data using ATAPI interface and your LSI rejected that request and so that RP stepped in and provided something fake to make the DSM use the disk at all. Theoretically it would be possible for RP to ask the SAS controller for the SMART using the SAS way and translate that information but this isn't a simple project. There are at least 6 different ways of asking for SMART. Three of them (!) are incorporated in parts (!!) into ATA/ATAPI. Of course SAS went a different direction and has way different ways of requesting and reporting SMART. It's a mess. With native syno SAS support their controllers seem to support ATAPI on SAS (probably custom firmware) and this is why on real hardware it "just works". Feel free to put an issue on GitHub in the redpill-lkm repo so we don't forget. However, we're certain it wouldn't be implemented very soon (but most definitely we would love to have that feature). As for the iLO 4 Advanced there's a beta key which happens to work on retail version. We don't know how legal is to use it but if you google it you can find it for free. Did they leve it on purpose? Is it some sort of an engineering key? Who knows. Most likely these keys for few bucks on ebay are these resold beta keys. The swap has to be done 100% of the time on 3615xs. The only time when you would want to leave it swapped is if you did swap them in your BIOS (i.e. set first serial port to 0x2F8 instead of 0x3F8). You can modify these values in the config if you need to move drives around. Don't modify them blindly - you need to understand it That ignore message means the RP ignored it as it doens't need to do anything with it. The kernel itself interprets that properly and configures the serial port. The issue is on 3615xs syno swapped ttyS0 and ttyS1, so if you type ttyS0 to the kernel it will really start sending data to a physically soldered port ttyS1 on the motherboard. You can swap the loader image and boot - then it will prompt you for PAT and just migrate as normal. But as others said: you should always have a backup as RAID is not a backup. Even if you run a ZFS on an official system for iX you should do a backup We are amazed by r/DataHoarders and their backups of 4-digit number of TBs. ...you do have a backup, right.... right?....right? There will be a clear instruction with the beta - stay tuned. This is an annoying "feature" of syno you've discovered few posts after The reason why it works from dev is that they implemented that security feature rather poorly. Normally to disable it you need to do "echo 1 >/proc/sys/kernel/syno_install_flag" and then you can mount /dev/synoboot freely. Keep in mind (or rather others reading it as you seem to know what you are doing) you should NOT edit ANY files in the image manually. Please, use the extension mechanism instead since we have it now. General tab is fixed for some time now (hwmon emulation). Can you publish the driver as an extension instead? We always try - all of us work/worked in development professionally and we realize how hard is to work with "clever" code. YOU know how it works when you wrote it. A week later neither you nor your friends know what's going on and everybody starts avoiding that part of the code like fire... after a year or two you have the same functionality implemented 5x by 10 different people and nobody knows what's going on. With RP we try to avoid that. It's nice that someone sees that effort. The only way to get SMART working is to pass the whole HBA device. In theory QEmu and others could proxy and filter SMART commands per drive but there's too great surface for attacks and weird behaviors for QEmu/VMWare to do it. You have to remember that "SMART" is really a combination of multiple unofficial ATA commands which were glued together by different manufactures. Then ATAPI tried to codify them and we got a ... huge mess held with several rolls of duct tape. This is why we have to step around a lot of undefined behaviors (like optional log directory SMART command which breaks DSM if it's not supported... but it's officially optional but someone assumed it's always there as modern drives support it). Are they... serious? Sharing a printer is one of the few nice features people actually use on NASes. It seems like a great candidate for an RP extension to run that script on boot Maybe you will like to contribute and create such one so it's an easy install? There are guides how to install NVidia drivers directly from spk from synology. This is the way to really do it. They offer them for their "AI" survivalence station model. This is actually a bug in canvas on FF with to strict privacy settings. We saw that somewhere else outside of DSM. We tried to search for that but no luck. All in all that's not a bug in DSM but in FF. There are canvas security settings in FF - if you make them more permissive for DSM address it should work. We think now it can be automated by an extension - let us know. For anyone who finds this: please, don't do it. We explained in the previous update post that a HWMON emulation was needed instead as putting these lines in. This is a standard AHCI controller. It should work out of the box - you're probably missing a proper Sata config extra_cmdline params and the drives connected to it "land" outside of the zone DSM scans. This is fixed now - it's was a race condition between partscan in linux and loop attachement. There's a plan to support real sensors and "emulate" values by reading them from sensors modules but emulating fake ones was an easier starting point than translating lm-sensors to syno-HWMON. You can still install lm-sensors or any other monitoring tools you like and monitor everything. It's not like syno API is accessible outside of CPU temp and HDD temps.... sadly. At least on non-syno hardware you have an option to use Linux tools - on real ones people are annoyed that they can't. At least we now know /proc entry can be read by a custom script if needed. There are many threads on syno form askim them for some monitoring beyond CPU temp. You should NOT change console parameter. This will break many things (DSM has secuyrity features checking for that parameter; RP assumes that it's at the platform-correct value etc.). We think the ship has sailed We will open a new thread with the beta release (which only really misses SAS and container support if we remember our own roadmap correctly). This topic will be probably closed and we will get a new one strictly for dev with maybe some moderators help to keep the stuff seprated DVA is on our roadmap for another reason - official NVidia drivers. The "AI" survivalence station is something which we personally have no interest in, but it will be there anyway if DVA is emulated. That excessive usage of CPU is actually a missed spinlock somewhere. The kernel doesn't monitor them in any way when debugging is disabled - it will "spin" [i.e. use all CPU cycles on a given core] forever if not unlocked. It's done that way in kernel as spinlocks usually last microseconds (so using other locks would waste even more CPU). When the lock is forgotten/lost somewhere a "deadlock" scenario arises. It will be detected only after some timeout and ideally when another lock tries to execute on the same CPU. It's very hard to debug that over all. ====================================================== Answers will continue in a separate post, as this post cites maximum number of 50 posts
  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 to backporting 2) Drivers modification 3) Kernel <=> driver modification 4) Data structures missing in toolchains for in-tree drivers Now let us explain each one of them separately and why this is an issue. There's a lot to unpack here. First lets address few terms which are used in kernel development: "in-tree" = code which exists within the source of the kernel; in terms of drivers it means you will find it under "drivers/" (e.g. in drivers/scsi/mpt2sas) "vanilla kernel" = source of the kernel which is the official version from kernel.org "kernel headers" = .h files present in the toolchain. These are NOT all kernel's .h files but only a subset of public API kernel provides. You will find these under "include" or in the syno toolchain. What's important they DO NOT contain private interaction between modules. That's why if e.g. mpt3sas driver wants something from mpt2sas you cannot use toolchain to compile mpt3sas and you NEED full sources. "upstream it" = make your custom patch for the kernel and get it accepted into the normal kernel sources 1) Versioning & backporting Syno, like many other companies, take the kernel and modify it in house. This is something which kernel devs don't really like but since it's an open-source project everyone can. However, after some time these companies realize they want new features from new kernel but cannot get them as their modifications no longer apply to a new version. What they do is "backporting". They grab their e.g. 3.10.108 which was modified to oblivion, then download the e.g. 3.19.0 and check commits which add features they want. They get that commit and apply to their 3.10.108 making it 3.10.109. This is incorrect and broken. But that't not the biggest problem. In case you don't see it: this poses a HUGE problem for using drivers from the vanilla kernel. Often times if you take a driver from vanilla 3.10 you will realize that suddenly doesn't work at all... as in fact they previously lifted a newer one from 3.20 and stuffed it in 3.10. Good luck loading such driver and using it. For that reason alone you CANNOT use vanilla kernel code as you don't know which version of the code has to be used. Sure, there are ways to figure this out, but the only sane approach is to use the source provided by syno. In case of small-ish bumps in kernel it's usually safe to get e.g. driver from kernel from 3.10.105 and fake the version compiling for 3.10.108 hoping not much changed. 2) Drivers modification Syno modifies in-tree drivers directly. To be honest they have no way around it as they apply vendor-specific hacks for e.g. timing bugs in certain chips. They should upstream it but... that's a different story and it's not as easy as it seems. Depending on WHAT was changed in the driver sometimes you can use kernel from a different kernel version. How do you know it's safe? Well... it's hard. If you don't have the sources for the new kernel (since if you did you wouldn't bother lifting the driver from an older version) you cannot know if the data structures changed. If they did you're pretty much toasted. Languages like C or ASM (or hardware in general) doesn't have magical way of discovering sizes of things. Everything is based on static assignment (ok, not everything, but lets make a simplification here). This means if syno decided to add a field to a struct [it's like an object] in mpt3sas driver and that field was added to a struct used ONLY in mpt3sas driver you can probably load the old driver and be fine. However, if they added a new argument to a "public" function (function used outside of the mpt3sas driver) or a new field to a struct used externally from the mpt3sas driver things may APPEAR to work. Every time such function is called or struct is used more and more memory and/or stack gets corrupted. Eventually you will crash something very badly and you will be lucky if that was at least the driver and not something unrelated which was just in the same area. In kernel there's virtually no protections of one piece of code breaking memory of the other. There are small protection for the kernel CODE itself and some sensitive areas but it's not like in the user space where one process trying to write into memory of another process will simply be killed - in the kernel you just corrupt the memory silently. 3) Kernel <=> driver interactions Scrolling through the questions we saw that some of you load drivers and see missing symbols. Well, this is the effect of 2). When they modify the drivers they often add their own hooks by just placing a f... gSynoFoo() call somewhere in the driver. Honestly we think it's very sloppy but it is how it is. The issue here is two-fold: if you compile a driver from vanilla kernel you will not have these calls so things may look correctly... but these calls were placed there for a reason and other things exepect them to happen. Sometimes the issue may be really small like performance drop or hibernation not working correctly. Sometimes you may step into a data loss with a certain controller which syno fixed in their kernel after getting a possible fix from the manufacturer... you don't know. if you try to add e.g. SAS to a non-SAS model things break badly. This is because it's not as simple as flipping the flag in synoinfo. By doing so you're telling the DSM "this model supports SAS". But the issue here is that models which REALLY support SAS have A LOT of code which is compiled only and only when the kernel config option for SAS was enabled. This config option being disabled literally REMOVED a bunch of code from many places when they compiled the kernel without SAS support. That's also the reason why getting SATA boon on 918+ was so challenging as the SATA-DOM code is literally removed on 918+. Bottom line is don't try to activate functions which depend on the kernel features being present. You can tweak number of disks, supported number of cameras and other user-land features but not re-enable features which are partially kernel and partially userland. It's like trying to pump diesel fuel into gasoline car after drilling a larger hole to fit the bigger diesel nozzle into the tank. There's no straightforward way to KNOW if the feature you want to activate has a kernel component. However, going through ALL options in synoconfigs/KConfig.* files will give anybody an idea what sort of things can or cannot be activated. In general anything involving in-kernel drivers is a no-no (e.g. iGPU acceleration will not work on 3615xs most likely but NVidia GPU probably will). 4) Data structures missing in toolchains for in-tree drivers You cannot get the code of a in-tree driver and compile it against the toolchain. This is because in-kernel drivers have access to many more things and link internal kernel files. Should they? Most likely no. However, the kernel is 30 YEARS OLD codebase and only recently they started to encapsulate drivers from using internal things. In most cases it's better to stick to the hardware which is officially supported. We have v7 sources for geminilake which we took some hints from (e.g. about synobios structures). If there's a particular driver we can look and compare with v6. However, if there's anyone who has experience with drivers (@IG-88?) we can share the archive in a PM as syno pulled it from SF. Why they did pull it? It's possible it contains code from e.g. broadcomm which is under an NDA and should never be published as it's not GPL.
  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 modules. In a system with just extra.lzma to get virtio we see 178 kernel modules - mptsas, mpt2sas, mp3sas, vmxnet, megaraid... and many many more which have nothing to do with the platform. Of course, naturally some drivers will have multiple kernel extensions as it makes no sense to separate them. For example VirtIO is technically like 5 drivers but we never saw anyone using just VirtIO-SCSI but not load VirtIO-NET. With some HBAs it may also make sense to make a bundle containing like 3 drivers for LSI cards. But definitely bundling e.g. VirtIO and LSI woudln't make sense. It's a delicate balance Same for CPU governor: for example we don't need it at all as we either want performance on a bare metal server-server or run it under a VM. This is why we didn't want to bundle it as many folks will not use it. To be honest the concept of power management on Linux is slightly foreign for all of us as we either lazily use Dells supported by Ubuntu or run Linux on servers which don't really care about PM.
×
×
  • Create New...