Stephen Borrill <netbsd%precedence.co.uk@localhost> writes:
With 10.1, modules.tar.xz does not contain
/stand/amd64-xen/10.1/modules, just /stand/amd64/10.1/modules. Is this
by design and should the modules work on a XEN3_DOMU kernel?
My understanding is that there were previously regular and xen modules
because of an ABI incompatibility in the regular/xen kernels, and I
think it was about maxphys. For 10, this was dealt with and there is no
need to have spearate xen modules. I don't remember if maxphys is the
same now, or if the module ABI was changed not to encode maxphys, or
something else.
I ask because:
# sysctl kern.module.path
kern.module.path = /stand/amd64/10.1/modules
My netbsd-10 systems, both dom0 and domU, show that path. However a 9 system
shows:
/stand/amd64/9.4/modules
On the dom0, I load zfs uneventfully (meaning theonly problem is the
high-RAM-usage lockup, which is not about modules). On a netbsd-current
domU, the path also lacks -xen, and zfs loads uneventfully as well.
# zfs list
[ 466.4000700] kobj_checksyms, 1004: [solaris]: linker error: symbol `sdt_provider_sdt' not found
[ 466.4000700] WARNING: module error: unable to affix module `solaris', error 8
[ 466.4000700] WARNING: module error: recursive load failed for `zfs' (`solaris' required), error 8
internal error: failed to initialize ZFS library
Are you sure that your modules and current after from the same build.sh
run?