Building kernel fails.

Kelly

New Member


Messages: 8

I have FreeBSD 11.1 amd64 installed on a DPDK-in-a-box system from Netgate.
I know it comes with Linux and DPDK works fine but want FreeBSD.
Trying to get DPDK working on the FreeBSD so that I can play around with it.

Installed DPDK from ports, install fine.
I used one of the instructions on the web to install DPDK on FreeBSD.
When I run the kldload contigmem.ko command I get an error.
KLD contigmem.ko: depends on kernel - not available or version mismatch
linker_load_file: Unsupported file type.

File of the /boot/modules/contigmem.ko give me.
/boot/modules/contigmem.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

So I tried building a new kernel and I get the following error.
make[2]: "/usr/sys/conf/kern.pre.mk" line 125: amd64 kernel requiers linker ifunc support.

I have gcc version 6.4.0 installed.

I do not see what is wrong.

Thanks for any help you can give.
 

ShelLuser

Son of Beastie

Reaction score: 1,718
Messages: 3,537

Why GCC? Clang is the default compiler on FreeBSD so I would definitely recommend using that over GCC.

Even so, this leads up the question: what's in your /etc/src.conf and /etc/make.conf files?
 
OP
OP
K

Kelly

New Member


Messages: 8

Why GCC? Clang is the default compiler on FreeBSD so I would definitely recommend using that over GCC.

Even so, this leads up the question: what's in your /etc/src.conf and /etc/make.conf files?
DPDK can be compiled with either gcc or clang. I tried clang first, it gave the above error so i tried gcc.
The kernel is being compiled with clang I believe, what ever is the default.

I make not changes to the aboe to files your talked about, so they ar the default.

Kelly
 

ShelLuser

Son of Beastie

Reaction score: 1,718
Messages: 3,537

I make not changes to the aboe to files your talked about, so they ar the default.
Sorry, but that doesn't tell me enough. You make it sound as if those files exist (how would you change non-existing files, right?). The problem with that though is that by default... those files don't exist.

Another thing... you say net/dpdk can be compiled using either Clang or GCC. How did you set that up? You could not have done that without editing /etc/make.conf. Well... I can think of ways how you could have, but that would most likely have seriously broken a thing or two, hence me asking.

Just installing lang/gcc is not enough for the system to actively start using it.
 
OP
OP
K

Kelly

New Member


Messages: 8

Sorry I was in a hurry and did not check my spelling or sentence structure before I clicked the Post button.

The DPDK documentation found at https://dpdk.org/doc/guides/freebsd_gsg/index.html tells you how you can compile the source with either clang or gcc and also how to install from ports collection.

Sorry again, for the misunderstanding but when compiling from net/dpdk I did not speify what compiler to use but you can when you try and compile it from source from the DPDK web site.

As for the files /etc/src.conf and /etc/make.conf, you are correct they do not exist. What I was just trying to say was that I did not add, create or modify these files.

I would have asked on the DPDK mailing list but thought FreeBSD forum might have an answer to the issue of compiling the kernel because I thought that the DPDK people would tell me to build a new kernel to over come the mismatch version issue.

I have been using FreeBSD since version 1 and maybe before that, it has been to long and my memory is not what it use to be :(
 

ShelLuser

Son of Beastie

Reaction score: 1,718
Messages: 3,537

Then I assume the source was also distributed with the whole setup? In that case my recommendation would be to grab the latest source tree and try building against that.
So...
  • # rm -rf /usr/src ; rm -rf /usr/obj/*
  • # svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  • # cd /usr/src ; make clean
And then proceed with your usual # make buildkernel. I tried looking up the error and something did pop up but that was a post dating back from 2014, so not much use right now. As such I can't help but wonder if your issue isn't somehow caused by an older source tree.
 
OP
OP
K

Kelly

New Member


Messages: 8

Then I assume the source was also distributed with the whole setup? In that case my recommendation would be to grab the latest source tree and try building against that.
So...
  • # rm -rf /usr/src ; rm -rf /usr/obj/*
  • # svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  • # cd /usr/src ; make clean
And then proceed with your usual # make buildkernel. I tried looking up the error and something did pop up but that was a post dating back from 2014, so not much use right now. As such I can't help but wonder if your issue isn't somehow caused by an older source tree.
I had to download the source from the Github mirror cause svn would timeout on me.
I successfully compiled a new kernel. The kernel config was a copy of the GENERIC config with the name changed to CUSTOM.

I recompiled the DPDK code both ways, net/dpdk and by downloading the source from DPDK.

I now get a new error when I try and load the contigmen module.
contigmalloc failed for buffer 0
module_register_init: MOD_LOAD (contigmem, 0xffffffff823ec000, 0) error 12

I have had no luck in searching for this new error with google.

I guess I need to post on the DPDK mailing list.

Thanks for you help.
 
OP
OP
K

Kelly

New Member


Messages: 8

I did finally get it to work, the 'contigmalloc failed for buffer 0' was that I had my buffer sizes to large and once I reduced them it worked.
I got this fix from the DPDK url above which told me what I had done wrong.
 

ShelLuser

Son of Beastie

Reaction score: 1,718
Messages: 3,537

I had to download the source from the Github mirror cause svn would timeout on me.
There's your problem then I think. Be very careful at this point.

The main Github respository doesn't carry releases but mainly the 12-CURRENT development snapshot. So if you grabbed that and tried to compile it it would definitely explain a few things. There's really no guarantees at all with that release. No guarantees that it can get build, that it can actually run and that it won't crash your entire system.

If you're dealing with an SVN timeout just cleanup and try again. It'll continue where it left off. So # svn cleanup and then perform the checkout command again.

So unless you actually planned on getting CURRENT I really think you should retrace your steps here.
 
Top