wbn

I have been struggling with this issue too! After some time debugging my kernel oops I was able to trace it back to this line of code: $ gdb vmlinux [snip] (gdb) l *mod_sysfs_setup+0x36c 0xffff8000081152b0 is in mod_sysfs_setup (kernel/module/sysfs.c:263). 258 #ifdef CONFIG_MODULE_UNLOAD 259 struct module_use *use; 260 261 mutex_lock(&module_mutex); 262 list_for_each_entry(use, &mod->target_list, target_list) { 263 ret = sysfs_create_link(use->target->holders_dir, 264 &mod->mkobj.kobj, mod->name); 265 if (ret) 266 break; 267 } (About `vmlinux`, apparently you should be able to decompress `vmlinuz` from the linux-image package to get this file, but I had no luck trying this. You can google it and give it a shot yourself if you like. I had been rebuilding my kernel to debug this issue so I was able to reuse the decompressed kernel image from `./cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64/vmlinux` inside the armbian build dir) It appears that the offending code is trying to create a symlink inside sysfs, and furthermore this behavior is controlled by the kernel config bit CONFIG_MODULE_UNLOAD. If you disable this bit, you will no longer be able to unload kernel modules while the system is running. I rebuilt the kernel with CONFIG_MODULE_UNLOAD unset and confirmed that inserting spl/zfs modules no longer triggers a kernel oops! But this can hardly be considered anything more than a temporary workaround. There is some other root cause going on here. I hypothesize that something is trashing the kernel's module or sysfs state somewhere, but I haven't made much headway into discovering what this could be. I did find a couple of instances of modules in the downstream vendor kernel doing irresponsible things with sysfs, including a lurking double-free for which I will submit a PR in due time, but none of these appear to be the bug I'm looking for. I should note that I'm not using zfs-dkms. I am building and installing ZFS from source from tag `zfs-2.3.0` instead. When I started debugging this, the arm64 package in ppa:arter97/zfs (which is mirrored by Armbian repositories) was partially missing, which prevented zfs-dkms and zfsutils-linux from being installed at the same time without downgrading. The arm64 build seems to be particularly flaky according to the build logs. This is to say that YMMV heavily, and I don't feel like re-testing this workaround with dkms yet, so if anyone else is interested enough to try this, let me know your results. FWIW the packages in the PPA appear to be fixed now.

Thanks. No, I didn't see that before. Having watched a bit of it, now I understand that there is a difference between the vector ISA extension implemented by the T-head core inside the D1 (0.7.1-draft) and the vector ISA extension targeted by the mainline kernel (1.0.0). I failed to catch this up until now. Well, it's not mentioned anywhere on the linux-sunxi wiki page for the D1, which is odd. But now looking through the comments on Reddit and Youtube and some kernel mailing list threads etc. I see that there has been an ongoing discussion about this for a while. In any case, of course this means that just compiling a mainline kernel with RVV support flags enabled won't make vector work on my Mango Pi MQ-Pro. Also, it won't do to use any random test program for RVV to test the D1's vector instructions, since those are likely to target the 1.0.0 spec as well. It looks like there are some demo programs that target the spec implemented by T-head specifically (xuantie-vector-demos), so I will try with those instead. But I don't expect to make much progress in light of this...

I went and recompiled the kernel from master using the existing configuration file, `make menuconfig` to turn on the RVV-related params, `make` and then `make bindeb-pkg` to generate dpkg archives. But no luck - installing the packages prevented my Mango Pi from booting so I'm on my backup SD card. I'm not able to connect to uart0 either, so I'm rather in the dark on what is going wrong during the boot process. I'll leave my modified kernel config file here for anyone who's interested, and keep experimenting with kernel builds. config-6.4.0+

@balbes150, thank you for your incredible work on these RISC-V builds. I am using the nezha 20230630-current sid image on my Mango Pi MQ-Pro and it works well. However there seems to be no vector extension (RVV) support. This makes sense because the vector support in the kernel is not yet included mainline (not even 6.4) as far as I can tell. Although @msomeone previously reported RVV support in 6.1.0-rc3 and I am curious how that was accomplished. In any case my `/proc/cpuinfo` does not report the V extension. $ cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc mmu : sv39 uarch : thead,c906 mvendorid : 0x5b7 marchid : 0x0 mimpid : 0x0 $ uname -a Linux chiyu 6.1.0-rc3-d1 #23.06 Fri Jun 30 21:26:26 MSK 2023 riscv64 GNU/Linux And attempting to run a test program (something like this) that contains a vector instruction will trap and halt the program. Program received signal SIGILL, Illegal instruction. add_data_vec_8 () at test.S:9 9 vsetvli t0, a3, e8,m1 # Vectors of 8b I would like some more information about enabling RVV on these boards, if that is possible. I could rebuild my kernel from the master branch using the config in `/boot` (plus enabling the RVV kernel config params), but I don't know if that would get me anywhere.