PeterSuh-Q3 / tcrp-addons

6 stars 4 forks source link

Quote for xpenology.com #1

Closed wjz304 closed 1 year ago

wjz304 commented 1 year ago

Sorry, when I replied, the xpenology.com forum popped up again and prompted me, causing me to be unable to reply image It seems that I can only provide limited responses within a cycle. So I can only give you some answers on here

arpl 是直接把  bzImage-to-vmlinux.sh -> kpatch ->vmlinux-to-bzImage.sh 后的kernel(zImage-dsm) 作为 syno 启动的 kernel 直接运行. 并没有生成 bsp 再patch到原有的syno kernel上的过程,

在很久之前我也尝试过生成kernel bsp,当时失败了,我就没有继续研究,转而也抛弃了 bsp 的形式,修改 redpill-load 直接使用patch后的 kernel. 这也降低了编译环境的复杂度。你也可以试试这种方式。 https://raw.githubusercontent.com/wjz304/redpill-load/main/build-loader.sh#:~:text=pr_info "Found patched zImage at \"%s\" - skipping patching %26 repacking" "%24{BRP_ZLINUX_PATCHED_FILE}" chmod,BRP_CACHE_DIR}/vmlinux-mod" "%24{BRP_ZLINUX_PATCHED_FILE}" rm -f "%24{BRP_CACHE_DIR}/vmlinux" "%24{BRP_CACHE_DIR}/vmlinux-mod"

另外,如果你生成的bsp 在 patch 后,syno如果能够运行并没有发生 kernel panic, 那么我觉得可能并不是 kernel的问题,lkm 和 modules的 影响也很大,

PeterSuh-Q3 commented 1 year ago

If so, I'm assuming that bsp already built with the kver4 toolchain works fine without a kernel panic, so there's no problem, and lkm has already used yours. There is the last issue, the module, and I am using pocopico's one compiled 2 months ago.

One suspicious thing is that synoboot1, synoboot2, synoboot3 partitions cannot be mounted normally. I am forcibly creating a node through the script of boot-wait, but this seems to be rather a problem. I'm still not sure what causes the synoboot partition mount to fail on the VM. Do you know why?

wjz304 commented 1 year ago

As I mentioned on xpenology.com, 7.1 and 7.2 use different toolchains, and there are incompatibilities in modules. After checking the modules.tgz, delete the usb*. ko related ko (as rd.gz contains these drivers) and try again

PeterSuh-Q3 commented 1 year ago

Yes, I will try to organize the module again according to your advice. The module of the case where 7.2 RC was recently successful in proxmox probably had a module related to usb*, but the file size is slightly different. The module on the right was successful in 7.2 RC.

스크린샷 2023-05-30 오전 12 13 54

As a result of rebuilding and testing now, I can install DSM, but I can't find the IP during the reboot process. It seems that something is causing a conflict between modules. We will inform you of the test results again.

PeterSuh-Q3 commented 1 year ago

I tested it with a module that removed usb*.ko first. DSM seems to be installed, but it doesn't reboot. Rebooting doesn't get me out of junior mode.

Second, I created a module that also removed xhci*.ko. However, the same phenomenon as above is repeated.

The modules used in the final build are shown below. https://github.com/PeterSuh-Q3/arpl-modules/releases/tag/v1.21

And the serial console log like below repeats.

[ 560.485902] BUG: scheduling while atomic: kworker/0:1/14/0x00000002 [ 560.486696] Modules linked in: uas hid_generic(E) usbhid hid(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) epyc7002_synobios(POE) leds_atmega1608(E) adt7475(E) hwmon_vid(OE) nfs_ssc(E) lockd(E) grace(E) sunrpc(E) hfsplus(E) md4(E) hmac(E) i40e(OE) auxiliary(OE) qede(OE) qed(OE) atlantic(OE) r8125(OE) r8168(OE) ixgbe(OE) be2net(OE) igb(OE) i2c_algo_bit(E) e1000e(OE) vxlan(OE) ip6_udp_tunnel(E) udp_tunnel(E) ip_tunnel(E) fuse(E) vfat(E) fat(E) glue_helper(E) crypto_simd(E) cryptd(E) ecryptfs(E) ecb(E) authenc(E) des_generic(E) libdes(E) ansi_cprng(E) cts(E) md5(E) cbc(E) cpufreq_powersave(E) cpufreq_performance(E) dm_snapshot(E) dm_bufio(E) dm_mod(E) crc_itu_t(E) crc_ccitt(E) sg(E) psnap(E) p8022(E) llc(E) ipv6(E) sha256_generic(E) libsha256(E) synorbd(POE) synofsbd(POE) virtio_pci(OE) virtio_mmio(OE) virtio_ring(OE) virtio(OE) e1000(OE) usb_storage xhci_pci xhci_hcd usbcore usb_common [last unloaded: epyc7002_synobios] [ 560.496632] CPU: 0 PID: 14 Comm: kworker/0:1 Tainted: P D W OE 5.10.55+ #64561 [ 560.497635] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 560.499013] Workqueue: 0x0 (events_power_efficient) [ 560.499638] Call Trace: [ 560.499961] [] dump_stack+0x57/0x6a [ 560.500606] [] schedule_bug.cold+0x4b/0x58 [ 560.501341] [] __schedule+0x5ec/0x8a0 [ 560.502019] [] ? _cond_resched+0x1a/0x60 [ 560.502718] [] schedule+0x64/0xe0 [ 560.503331] [] worker_thread+0xc6/0x3e0 [ 560.504021] [] ? process_one_work+0x3c0/0x3c0 [ 560.504791] [] kthread+0x12d/0x150 [ 560.505427] [] ? kthread_bind_mask+0x60/0x60 [ 560.506185] [] ret_from_fork+0x1f/0x30

wjz304 commented 1 year ago

Syno * is also recommended to be deleted

wjz304 commented 1 year ago

Or what network card do you use and only put in the relevant network cards? Eliminate unnecessary driver issues first

wjz304 commented 1 year ago

I took a look, there are 353 driver files in your package, and that the file I compiled currently only contains 70 files.

PeterSuh-Q3 commented 1 year ago

thank you

Replaced with your epyc7002-5.10.55.tar which has 70 modules. 7.2-64561 DSM installation test came out successfully as below.

스크린샷 2023-05-30 오전 9 36 24

I forked arpl-modules of fabio as below and merged them by copying pocopico's to fabio's module that I compiled. In the process, the number of modules increased to 353. https://github.com/PeterSuh-Q3/arpl-modules/tree/main/epyc7002-5.10.55 https://github.com/pocopico/redpill-modules/tree/master/epyc7002-5.10.55

It seems that you can use all of pocopico's modules only after going through a verification process by removing unnecessary modules one by one.

wjz304 commented 1 year ago

Yes, it's not easy to troubleshoot. There are still some incompatible drivers among the 70 I am currently using, and I haven't found them yet