Jump to content
XPEnology Community

Automated RedPill Loader (ARPL)


fbelavenuto

Recommended Posts

5 hours ago, Orphée said:

@pocopico I did not play with sata_remap (I did not understand it)

But with Proxmox machine set to q35, there is always this dummy/unused first controller you must handle/add in SataPortMap. but no matter what you try with DiskIdxMap, the first disk shown in DSM start in slot 2.

If you switch machine to default i440fx, no more dummy/unused sata controller, but when you need to passthrough PCI-e, q35 is recommanded, if not mandatory.

 

Edit :

If you look my current boot line conf from DMESG :

 

 

image.thumb.png.660edf79020635b310740ef8d1bf1a2d.png

 

  Reveal hidden contents

 

 

image.png.00f0d669e3b067fdb209c3aa5f4c9d56.png

 

3 hours ago, jrac86 said:

Thanks everyone who helped me realize my mistake. I put the SataPortMap and DiskIdxMap in the correct place. I still get 2 dummy blank ports in the first 2 slots, but better than 12 of them lol. 

 

So there is no way to get rid of those dummy other than using i440fx instead of q35? Is there a performance hit using i440fx? I know I have to set my HBA card to not use pcie when using i440fx. I just have no idea what difference it makes.

I had this same battle. @flyride helped me in that link @pocopico posted on page 14... To get your HBA to start at slot 1 use i440fx system in proxmox, not Q35. Pci passthrough still works. I honestly do not know what, if any, advantages are to q35 vs i440fx in proxmox.  My system (ds3622) has been in production for many weeks, is used as a backup server for ABB and HB nightly and has given me zero problems.  I do not know if there are performance hits or not, I would be happy to test any performance procedures.  In the end, I agree its purely cosmetic, but I wanted it to be correct, and because I saw no difference in the use case of my DSM instance, no performance hit, no operational difference, I choose i440fx. I get all actual smart data from drives, including serials, models, and temperature from the HBA in pci passthrough.

 

If any has or knows if there are any performance or use differences between q35 and i440fx I am all ears.

vm100.thumb.jpg.a0f426982dd352d843d17d0a933695b5.jpg

image.png.ff9a93b06bac44dace1840eb9ff525ac.png

image.thumb.png.e218b71256e631b96eb38aadaf6b3118.png

Link to comment
Share on other sites

@fbelavenuto with your recent changes in the compilation process, the modules now are loading fine :) 

 

Still though the dirty flag is not set so i had to run the patch ramdisk manually after the update of the modules.

 

EDIT: I have just tested v1000 and vmxnet causes the same oops condition when loading :


 

[    3.191142] DMAR: 32bit 0000:13:00.0 uses non-identity mapping
[    3.195916] BUG: unable to handle kernel NULL pointer dereference at           (null)

 

This though has been fixed for vmxnet3 on DVA1622 (geminilake) that i've tested as well.

Edited by pocopico
  • Like 1
Link to comment
Share on other sites

how I assembled the bootloader based on 3622xs +, it does not find it either in findsynology or in synolgy assistsstant, if you install 920+, then everything works. How to fix everything so that 3622 will work? Maybe write something in cmd?

I also tried on 920+ maxdisks 8 but it still only shows 4.

3615 comes to installation, but after 10 minutes "something went wrong". Only 920+ is installed, but it is not possible to increase the number of disks

Edited by SWAGG3R
Link to comment
Share on other sites

On 7/22/2022 at 7:32 PM, mrmvd said:

When I try to rebuild loader, I see error:

 

Screenshot_1.png.bd42fc0f04467b14d8c70410f8ea748e.png

 

Some strange bug!!

 

On 7/22/2022 at 7:32 PM, mrmvd said:

Also I see only 6 of 8 HDDs connected to my Adaptec 8405 card thru expander
 

On 7/22/2022 at 7:32 PM, mrmvd said:

BTW, Is Mellanox Connect-X 2 supported?

No yet, I couldn't compile the sources!

 

 

 

Link to comment
Share on other sites

New alpha version released:

 

https://github.com/fbelavenuto/arpl/releases/tag/v0.3-alpha4

 

Custom MAC address now works for the loader too!

Update modules set dirty flag, loader warns to rebuild loader.

Synoinfo now is copied to user config, then the user can remove undesirable(unwanted) entries

New option in grub: Force DSM re-install

Edited by fbelavenuto
  • Like 3
  • Thanks 2
Link to comment
Share on other sites

1 hour ago, fbelavenuto said:

New alpha version released:

 

https://github.com/fbelavenuto/arpl/releases/tag/v0.3-alpha4

 

Custom MAC address now works for the loader too!

Update modules set dirty flag, loader warns to rebuild loader.

Synoinfo now is copied to user config, then the user can remove undesirable(unwanted) entries

New option in grub: Force DSM re-install

 

This is awesome work! Much appreciated! 

  • Like 1
Link to comment
Share on other sites

5 hours ago, fbelavenuto said:

Thanks for the log, kernel panic in tg3 module!!!

 

 

@fbelavenuto i see you are somehow storing a kernel config file for each platform. Is this kernel config file modifed after copying the $(kernelfolder)/synoconfig/(platform) to the .config and issuing make oldconfig ? 

 

have a look here :

 

https://github.com/RedPill-TTG/redpill-lkm

 

Link to comment
Share on other sites

4 minutes ago, pocopico said:

 

@fbelavenuto i see you are somehow storing a kernel config file for each platform. Is this kernel config file modifed after copying the $(kernelfolder)/synoconfig/(platform) to the .config and issuing make oldconfig ? 

 

have a look here :

 

https://github.com/RedPill-TTG/redpill-lkm

 

 

Yep! I added modules via "make menuconfig", compile and run "make savedefconfig"

Link to comment
Share on other sites

12 minutes ago, fbelavenuto said:

 

Yep! I added modules via "make menuconfig", compile and run "make savedefconfig"

 

So you copied the included [platform specific synoconfig file, then you've modified the modules list and then saved. That should be OK ... were are these null pointer coming from then ? 

 

I've noticed also that the released kernel sources are per a bunch of different plaforms, I've downloaded a per plaform kernel and store it on a different folder, can this be the reason ? I mean maybe they have different modified headers and or symbols per platform but these should be under the build forder right ?

Edited by pocopico
Link to comment
Share on other sites

9 minutes ago, pocopico said:

 

So you copied the included [platform specific synoconfig file, then you've modified the modules list and then saved. That should be OK ... were are these null pointer coming from then ? 

 

I've noticed also that the released kernel sources are per a bunch of different plaforms, I've downloaded a per plaform kernel and store it on a different folder, can this be the reason ? I mean maybe they have different modified headers and or symbols per platform.

 

I downloaded the sources for each platform, put them in the docker image that I use to compile, so it's no problem to use headers from one platform to compile from another platform.

I realized today that the same module "virtio_net.ko" compiled for geminilake works on 918+ but gives kernel panic on 920+! (Sorry, my mistake, these models are from different platforms, I'm starting to confuse things, time to take a break :D)

 

I'm trying to understand where the error is!

Edited by fbelavenuto
  • Like 1
Link to comment
Share on other sites

6 minutes ago, fbelavenuto said:

 

I downloaded the sources for each platform, put them in the docker image that I use to compile, so it's no problem to use headers from one platform to compile from another platform.

I realized today that the same module "virtio_net.ko" compiled for geminilake works on 918+ but gives kernel panic on 920+!

I'm trying to understand where the error is!

 

In any case, the fact is that i have both kernel sources per plafform and the toolchain in different docker images and i compile them using a similar script to the one you are using.

 

That is strange indeed. I got this same oops if i accidentaly mixed platforms (didnt issue a make clean prior moving to next platform) , so i deciced to also use different kernel source path per platform as well. 

Edited by pocopico
Link to comment
Share on other sites

3 minutes ago, pocopico said:

 

In any case, the fact is that i have both kernel sources per plafform and the toolchain in different docker images and i compile them using a similar script to the one you are using.

 

That is strange indeed. I got this same oops if i accidentaly mixed platforms (didnt issue a make clean prior moving to next platform) , so i deciced to also use different kernel source path per platform as well. 

A curiosity is that most modules compiled using synology's GPL source cause kernel-panic. To work I compile it with vanilla kernel sources using the toolkit.

I'm wrong somewhere, I'm just not seeing it yet.

 

My separated folders:

 

image.png.1a68afb26189e2211ca0719b5b70e55c.png

 

 

Link to comment
Share on other sites

39 minutes ago, fbelavenuto said:

A curiosity is that most modules compiled using synology's GPL source cause kernel-panic. To work I compile it with vanilla kernel sources using the toolkit.

I'm wrong somewhere, I'm just not seeing it yet.

 

My separated folders:

 

image.png.1a68afb26189e2211ca0719b5b70e55c.png

 

 

 

I dont think that syno released kernel differs much from vanilla in the modules section. But you never know. So i prefer to download each for each platform and then compile using the toolkit.

Link to comment
Share on other sites

19 hours ago, pocopico said:

 

I dont think that syno released kernel differs much from vanilla in the modules section. But you never know. So i prefer to download each for each platform and then compile using the toolkit.

 

Testing with virtio I found that in geminilake what generates kernel-panic is virtio_scsi.ko. To clear the doubt if it is a problem with me I managed to reproduce the same problem in tcrp:

Spoiler

Loading kmod #6 "virtio_scsi.ko" for thethorgroup.virtio (args: )
[    3.010435] scsi host6: Virtio SCSI HBA
[    3.014968] scsi 6:0:0:1: Direct-Access     QEMU     QEMU HARDDISK            2.5+ PQ: 0 ANSI: 5
[    3.016213] <redpill/scsi_notifier.c:65> Probing SCSI device using sd_probe_shim
[    3.017205] <redpill/scsi_notifier.c:77> Triggering SCSI_EVT_DEV_PROBING notifications
[    3.018183] <redpill/sata_port_shim.c:66> Found new disk vendor="QEMU    QEMU HARDDISK   2.5+" model="QEMU HARDDISK           " connected to "Virtio SCSI HBA" HBA over non-SATA port (type=0) - fixing to SATA port (type=1)
[    3.020506] <redpill/scsi_notifier.c:87> Calling original sd_probe()
[    3.021349] BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
[    3.022319] IP: [<ffffffff813f422a>] sd_probe+0x6da/0x8f0
[    3.022319] PGD 35b1d067 PUD 1615067 PMD 0 
[    3.022319] Oops: 0000 [#1] SMP 
[    3.022319] Modules linked in: virtio_scsi(OE+)

 

So I conclude that the problem is some code modified on the geminilake platform.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...