Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Kernel modules on 10.1



On Tue, 18 Mar 2025, Greg Troxel wrote:
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.

Yes, it was MAXPHYS. You needed to build the zfs module with MAXPHYS=32768 to match the kernel (which was not actually done, so it needed manually building anyway).

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?

EPARSE :-)

Yes, from the same run (freshly downloaded from netbsd.org).

The problem is that GENERIC and the modules are built with KDTRACE_HOOKS, but XEN3_DOMU is not.

--
Stephen


Home | Main Index | Thread Index | Old Index