jun

A kernel config related to pci is changed, so all non official pcie device drivers are broken. 通过我的 ONEPLUS A5000 上的 Tapatalk发言

yes, that is what I means by "stable SAS disk name"

since you are using a external sas enclosure, that is a setup I've never experimented before, here is my educated guess: You issue is caused by my implementation of stable Sas disk naming, the disk name is simply derived from sas remote phy id plus SasIdxMap as start position. I think ports directly connected to hba card are 0-7, and external expansion cards inside your enclosure will start from 8 You can try to set SasIdxMap=0xfffffff8, that is -8 to move start position to 0 if that does not work, simple remove SasIdxMap option, then sas disk names should occupy unused slots as before.

Hi, options not available in vanilla DSM are hidden in /proc/cmdline here is a example of disk order related options: SasIdxMap=0 DiskIdxMap=080C SataPortMap=4 it should works like this: DiskIdxMap make first sata controller start from disk 8, second from disk 12 etc, SataPortMap limit the number of disks a sata controller can have(vmware's virtual sata controller have 32 ports!) then SasIdxMap make SAS controller start from disk 0, as a plus, this option should give you a stable SAS disk name

Hi, everyone, Thanks for you patience. A new ds918 loader support 6.2/6.21 is uploaded. whats new: uefi issue fixed. i915 driver updated. link https://mega.nz/#F!Fgk01YoT!7fN9Uxe4lpzZWPLXPMONMA (for DS918+) - v1.04b ---Beginning of addition by polanskiman--- link https://mega.nz/#!OV4gVKyZ!dCgfXx1bgAOyvbFwFiov3s7RSNoFuqnAcNmSllLoUiw (for DS3615xs) - v1.03b link https://mega.nz/#!zcogjaDT!qIEazI49daggE2odvSwazn3VqBc_wv0zAvab6m6kHbA (for DS3617xs) - v1.03b Please read this topic to know what loader to chose: ---End of addition by polanskiman---

As DSM 6.2 finally released, I spent a few days to identify new kernel side validation mechanism, and got some ideas to work around it, the early-stage experiment seems work, so, the exciting part(for me) is done. A new loader will be released when it is ready.

ds916 version is not a generic build, it's for boards similar to official ones, otherwise no point to use it 通过我的 ONEPLUS A5000 上的 Tapatalk发言

synology stripe comments and replace ifdefs to meaningless myabc in the kernel source，i believe that is the cause of the incompatibility

because the loader packs a earlier kernel & ramdisk with it, and they are expected to be upgraded to latest version during install or upgrade process. that is how the loader is able to support multiple dsm version, and allows you to apply latest security fix, if kernel version code does not change.

Sorry, fixed

its an old script bug due to my oversight, I am uploading a new version to fix it, hopefully without introduce new bugs

One thing worth noting, that the four 1b4b:9235 's are fake pci devices to emulate DS3615xs, so they do not need extra driver even if they are real devices. btw, your article about ubuntu on windows is really interesting

Trying to understand the current situation here. Does the undefined instructions complain affect machines running e3-1230 v2 with esxi being the underlay OS? ds916p is for braswell family processors (j3160 n3710 etc), there seems no much point to run it on e3 except debugging the loader.

DS916 is added for hardware transcoding support, and its kernel is optimized for intel's braswell family processors. For desktop/mobile processors, 4th Gen Core processor or later is required to provide necessary instruction features. for example, i7-4700mq works, but e3-1230v2 complains about undefined instructions. Ok then I guess someone with the required hardware should test it. By the way, what did you add/fix on v1.02a2? I enabled mcu emulation for ds916p/ds3617 to deal with "time bomb" problem, plus as you notice, standalone patcher is provided for interested guys, though I think peoples want to recompile the loader should be able to extract it from the img. These models (in fact, I believe all new models) expect some kind of challenge/response through serial port with on board mcu. I solve this by emulate a serial port to response this kind messages in kernel.

DS916 is added for hardware transcoding support, and its kernel is optimized for intel's braswell family processors. For desktop/mobile processors, 4th Gen Core processor or later is required to provide necessary instruction features. for example, i7-4700mq works, but e3-1230v2 complains about undefined instructions.

sata and usb here refers to the boot device of the DSM, usb for baremetal and sata for VM

some DSM models has extra checks after running around a few hours, if this check is not passed, a few .so will be deliberately corrupted, the code to deal with this is not enabled for the model if you see "device not supported" in the kernel log

Same error over here too after each reboot. As a matter of fact, found that on the 6.0.2 the SSD (500GB) 200 of used space after upgrading to 6.1 it shows that 254GB used space - seems like 54Gb puff gone Is that the case on your Nas too ? Not really. All my pre existing volumes maintained the same used/free space ratio, and my SSD that I use as cache it's working properly and with the correct size/space available. Anyone has any tips on debugging this issue? If you have a look at grub.cfg, notice that "Force Install" entry has a extra argument "syno_port_thaw=1", that is the option to prevent kernel complaining disk disabled problems, you may want to add this option to normal boot menu entry to see if it helps.

I've rebased the vendor changes on 3.10.77 to 3.10.102, seems still works. jun your are the MAN Next step is I think to troubleshoot the network issue on some system that "prevent" network driver to load at boot. How can I (or the community) help you to debug ? How do you display/access the early boot stage without serial console ? Based on my unintentionally migration from ds3615xs to ds3617sx, and feedbacks from this forum, I guess some drivers are not correctly updated in the rootfs, thus caused network failure, a clean installation does not suffer from this problem. I use VM to do preliminary test, does not have the luxury to test on baremetals. As before, I do not have much time to build and test drivers, if developers and users can help in these area, then more hardware will be supported.

Yes, AMD loader need some extra work.

I've rebased the vendor changes on 3.10.77 to 3.10.102, seems still works.

This version of loader (and synology's version) does not have driver for ohci usb controller, a host controller for usb 1.x. Why it is not included in the loader? Because I did not notice it was not included. Why not for synology? My understanding is that, Intel invent UHCI for usb 1.x, so normally, intel chipsets will never have OHCI controllers, nowdays even UHCI's are uncommon, lots of usb 2.x/3.x controller seems include builtin hubs to do the translation for usb 1.x devices. In your use case, the external hub simply acts as a usb 1.x to usb 2.x translator, that is a viable workaround for the moment. I will make sure this driver is availble when next release is out, developers can also compile ohci-hcd yourself.

I thought one second is enough Next update maybe change the timeout= parameter to default to 3 or 4 seconds. Should be plenty enough Press up/down key before the menu is shown, the same way as you enter BIOS setup screen

The new kernel will not in effect, unless manually copy it to the right place. Since Intel machines are in fact using unmodified synology kernel, I am considering restructure the boot partition's to closely match synology's, so that new kernel will take effect automatically, but this has the potential risk of a small upgrade may break a working system.

Since there are considerable difference between beta source and the release version, I write and compile kernel modules instead, even the AMD kernel is a combination of the original kernel and the AMD support code compiled as module (sort of). I compile beta src kernel only to aid debugging, itself does not work properly, lacking required symbol etc, and I do not bother to fix it. Thanks for the reply, jun! I am trying to make hv_balloon.ko, hv_utils.ko, hv_vmbus.ko, hv_netvsc.ko, hv_storvsc.ko load correctly as kernel module, but I get unknown symbol error, by checking dmesg output, there are many unknown symbols, for example: [436076.774681] hv_vmbus: Unknown symbol hv_register_vmbus_handler (err 0) [436076.774985] hv_vmbus: Unknown symbol x86_hyper_ms_hyperv (err 0) [436076.775042] hv_vmbus: Unknown symbol pv_cpu_ops (err 0) [436076.775055] hv_vmbus: Unknown symbol x86_hyper (err 0) [440432.878847] hv_vmbus: Unknown symbol hv_register_vmbus_handler (err 0) [440432.878871] hv_vmbus: Unknown symbol x86_hyper_ms_hyperv (err 0) [440432.878885] hv_vmbus: Unknown symbol pv_cpu_ops (err 0) [440432.878914] hv_vmbus: Unknown symbol x86_hyper (err 0) [440463.877528] hv_utils: Unknown symbol vmbus_driver_unregister (err 0) [440463.877545] hv_utils: Unknown symbol vmbus_sendpacket (err 0) [440463.877556] hv_utils: Unknown symbol vmbus_prep_negotiate_resp (err 0) [440463.877568] hv_utils: Unknown symbol vmbus_close (err 0) [440463.877578] hv_utils: Unknown symbol vmbus_recvpacket (err 0) [440463.877600] hv_utils: Unknown symbol cn_netlink_send (err 0) [440463.877611] hv_utils: Unknown symbol vmbus_open (err 0) [440463.877625] hv_utils: Unknown symbol cn_del_callback (err 0) [440463.877700] hv_utils: Unknown symbol __vmbus_driver_register (err 0) [440463.877717] hv_utils: Unknown symbol cn_add_callback (err 0) [440706.396491] hv_vmbus: Unknown symbol hv_register_vmbus_handler (err 0) [440706.396518] hv_vmbus: Unknown symbol x86_hyper_ms_hyperv (err 0) [440706.396532] hv_vmbus: Unknown symbol pv_cpu_ops (err 0) [440706.396545] hv_vmbus: Unknown symbol x86_hyper (err 0) Then maybe let's start with pv_cpu_ops, I checked the reference and dependency of this symbol in below link: c Any suggestions on how to make such symbol loadable as a kernel module based on above link's information? not possible unless you've managed to compile the missing code as module, as you may notice, these code are normally compiled as part of the kernel(and for a good reason), so you need hacking the code to make it work, that's the hardest part. EDIT: I've been a bit careless reading your question, you clear know most of the above info.