Created attachment 866002 [details] emerge info 1) emerge -v vhba 2) modprobe vhba > modprobe: ERROR: could not insert 'vhba': Unknown symbol in module, or unknown parameter (see dmesg) > dmes ... > [ 7413.086446] vhba: Unknown symbol preempt_count_sub (err -2) > uname -a > Linux dragonworld 6.1.19-gentoo #2 SMP PREEMPT_DYNAMIC Mon May 1 12:52:12 CEST 2023 x86_64 AMD Ryzen 7 7700X 8-Core Processor AuthenticAMD GNU/Linux
That's a pretty old kernel, if you never replace it and clean old modules, it's possible you still have a old version of the vhba module at the old location and it's loading that one instead (portage has protection for these and does not remove them). I think(?) old would be /lib/modules/6.1.19*/misc/vhba.ko, while the new likely-not-broken one will be extra/vhba.ko `find /lib/modules -name vhba.ko` if in doubt I did try to have a fix for issues like that but it ended up causing issues with dracut instead and got reverted.
Pretty old? It's from June 18th. I would not call this old. I removed now all module directories except the one of 6.1.19 . I re-emerged vhba and modprobe it again but the same error happens. So it's not old module directories causing the problem.
And the file name of the module is: /lib/modules/6.1.19-gentoo/block/vhba.ko
(In reply to Plüss Roland from comment #2) > Pretty old? It's from June 18th. I would not call this old. I guess, but it's 19 versions behind the current stable 6.1.38, and is gone from the tree. Fortunately I don't think(?) that one was affected vulnerabilities, albeit cleaned kernels often are. Tend to be easier for us if testing against the current kernels though. (In reply to Plüss Roland from comment #3) > And the file name of the module is: /lib/modules/6.1.19-gentoo/block/vhba.ko That's the only one then? I guess it's not what I thought it may be then. Given you are using stable I guess this is still the old ebuild anyway.
Attach your .config, please
Created attachment 866184 [details] kernel config
(In reply to Plüss Roland from comment #6) > Created attachment 866184 [details] > kernel config I tested with your config and gentoo-sources-6.1.41 and had no issue loading the module [Jul25 13:24] vhba: loading out-of-tree module taints kernel. [ +0.000912] scsi host5: vhba
I'm sorry for asking the obvious but did you rebuild vhba against the kernel you are currently running? Please double-check vhba build log that it's being built against the correct kernel.
Also it could be the reason that kernel and module were compiled by different gcc (versions/USE).
Created attachment 866300 [details] console log emering vhba
Yes, I emerged it multiple times during this bug report.
My impression is as mgorny says, perhaps version is the same but your built kernel is mismatching with the one you have installed (aka may have some differences and makes it so it builds with some symbols that aren't available at runtime). wrt gcc it also wouldn't hurt to `make clean` your kernel, then make && make install it back, and boot that one Albeit while doing all this may as well just upgrade your kernel too.
(In reply to Plüss Roland from comment #10) > Created attachment 866300 [details] > console log emering vhba Does not seem to be the only issue too, aka: * Updating module dependencies for 6.1.19-gentoo ... depmod: WARNING: //lib/modules/6.1.19-gentoo/kernel/drivers/video/backlight/lcd.ko needs unknown symbol fb_unregister_client depmod: WARNING: //lib/modules/6.1.19-gentoo/kernel/drivers/video/backlight/lcd.ko needs unknown symbol fb_register_client depmod: WARNING: //lib/modules/6.1.19-gentoo/kernel/drivers/virtio/virtio_pci.ko needs unknown symbol pci_vfs_assigned ... Just seems things have gotten out of sync, some of these may still load but that'd means depmod is getting wrong information.
I rebuild the new kernel. Had first problems that the module could not be loaded due to exec format error but after a couple of rebuilding in a loop it worked. Kinda unstable getting that module to work but it eventually worked.
Seems this is resolved now, but I would take a close look at the health of your hardware. This is a normal process that should not have this level of variability.
