Re: Kernel modules on 10.1

[Greg Troxel <gdt%lexort.com@localhost>]

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?



I interpret Manuel's comment to mean that with modules, you always have
the risk that things are messier than they are supposed to be, which is
a separate comment from an assertion that there are known specific
problems.