FreeNAS 9.2 building additional kernel module

[David E]

Hi all-
I'm working on building VMware's vmxnet3 for FreeNAS 9.2 (the supplied version in tools no longer works). I integrated it into FreeNAS's build, and it even was auto packaged up into the install ISO. However I have a few questions for the release engineering experts:

-Is there some easy way to build just a kernel module for FreeNAS, without having to build the entire system? Specifically, how do I get all the paths/flags set up properly to point to FreeNAS's kernel/system headers.

-When I build the system, (make release), the kernel name turned out to be 9.2-RELEASE-p3, whereas the actual released kernel name is 9.2-RELEASE, I believe this is preventing me from kldloading my built module into a standard 9.2 release install. How can I change this name?

-When I run kldload vmxnet3, I get:
link_elf_obj: symbol __mtx_assert undefined
linker_load_File: Unsupported file type
kldload: can't load vmxnet3: Exec format error

I took a look through the sources, and __mtx_assert definitely exists in the kernel source code, and I didn't see any obvious reasons it would be being stripped during build or not included, any suggestions on how to proceed to diagnose this? Is there some naming strip/rewrite that is not properly being performed on vmxnet3? vmxnet3 compiled fine during the build.

Thanks!

ps before anyone says 'you shouldn't run FreeNAS virtualized', I am physically passing through a LSI-hba to the VM that has all the drives it uses directly connected to it, and it has 16GB of RAM, so I think it is a legit use :)

 

[Dusan]

-When I build the system, (make release), the kernel name turned out to be 9.2-RELEASE-p3, whereas the actual released kernel name is 9.2-RELEASE, I believe this is preventing me from kldloading my built module into a standard 9.2 release install. How can I change this name?

If you just checkout the GIT HEAD then you are basically building a 9.2.1 "nightly". To build 9.2.0 checkout the 9.2.0-RELEASE tag. I think you also need to instruct the build system to checkout the related TrueOS (FreeBSD) tag by setting GIT_FREEBSD_TAG=9.2.0-RELEASE before you start the build.

 

[David E]

If you just checkout the GIT HEAD then you are basically building a 9.2.1 "nightly". To build 9.2.0 checkout the 9.2.0-RELEASE tag. I think you also need to instruct the build system to checkout the related TrueOS (FreeBSD) tag by setting GIT_FREEBSD_TAG=9.2.0-RELEASE before you start the build.

Thanks for the reply, I was on the 9.2.0-RELEASE tag, ie:

Code:

root@freebsd:/tank/freenas # git branch -a
* (detached from 9.2.0-RELEASE)

When I ran make release it auto-checked out FreeBSD/src and ports without manual intervention, here is the branches they are on:

Code:

root@freebsd:/tank/freenas/FreeBSD/src # git branch -a
* feature/unified_freebsd
  remotes/origin/HEAD -> origin/feature/unified_freebsd
  remotes/origin/feature/hyperv
  remotes/origin/feature/unified_freebsd
  remotes/origin/freenas-9-stable
  remotes/origin/freenas-9.1-releng
  remotes/origin/pcbsd-9-stable
 
commit 07c8abb42e2a505a5dc920282fa2378dd5f59a25
Author: Alexander Motin <mav@FreeBSD.org>
Date:  Thu Jan 23 00:20:22 2014 +0200
 
    Mostly revert r260267 and hopefully really fix the original problem.
   
    The latest draft of SBC-3 tells: "A MAXIMUM UNMAP LBA COUNT field set to
    a non-zero value indicates the maximum number of LBAs that may be unmapped
    by an UNMAP command."  To me it does not sound like that limit is set per
    single descriptor, but rather per all command.  And I have at least one
    device that behaves exactly that way.  This patch fixes the problem there.
 
root@freebsd:/tank/freenas/FreeBSD/ports # git branch -a
* freenas/9.1-stable-b
  remotes/origin/HEAD -> origin/freenas/9.1-stable-a
  remotes/origin/freenas/9-stable
  remotes/origin/freenas/9.1-releng
  remotes/origin/freenas/9.1-stable-a
  remotes/origin/freenas/9.1-stable-b
  remotes/origin/jkh-samba41
  remotes/origin/master
  remotes/origin/svn_head
 
commit 47b2144900b85a84b5d6904fde0d34ea79715940
Author: John Hixson <john@ixsystems.com>
Date:  Sun Dec 29 14:22:00 2013 -0800
 
    Update Samba4 port to 4.0.13

Do I need to manually change either of these? I had expected the revisions needed (or submodules) to be committed into the FreeNAS repo.

 

[Dusan]

I had expected the revisions needed (or submodules) to be committed into the FreeNAS repo.

I don't think so. As you can see it checked out the feature/unified_freebsd HEAD -- last commit is only few days ago. If you check do_build.sh (https://github.com/freenas/freenas/blob/master/build/do_build.sh#L351) it seems you can set GIT_FREEBSD_TAG to override that. Setting GIT_FREEBSD_TAG=9.2.0-RELEASE should do the trick (https://github.com/trueos/trueos/tree/9.2.0-RELEASE). You can do the same for PORTS, but as you only care about the kernel module you probably don't need to bother.

 

[mstang1988]

Any updates on the build of this module? I would like to pull it into my sandbox testing of 9.2.1

 

[Miky]

I am interesting in this problem too. I'm experiencing same result.

EDIT: OK, kernel module is compiled and working, so far. I had to set git tag '9.2.0-RELEASE' for 'ports' and 'src' too.

 

[David E]

Yep thanks Dusan, got everything to work. I posted the driver here: http://forums.freenas.org/threads/vmxnet3-ko-for-freenas-9-2-0-in-esxi-5-5.18280/ for anyone else that wants it.