Fedora Core 6 How-to

[JohnNavratil]

Greetings to all, and thanks for everyone's work here.  As a compete newbie (as of last Thursday) to NI and NIKAL, I wonder if someone could thread all this together for me.  The last time I built a kernel was in the days for RedHat 5.2.  I'm running Fedora Core 5 with the 2.6.20 kernel.  I'm inclined to crawl over the task of getting 2.6.20 to work, although I could roll back.  My goal is to write a simple controller for gas sampling using the base C API.  My task at the moment is to educate myself on the available tools,  and I am solidly at step zero.

Customer support sent me off with the RedHat iso 'NIDAQ800_RedHat.iso' which, of course, failed to build NIKAL.  Searching lead me to this thread, but I just can't quite seem to piece this all together.  Should I start with the RedHat iso then install the Nikal 1.5?  I started with an unmodified install of the RedHat iso, but when I tried the patch, I received:

<pre>
[root@linux nikal]# patch -p1 < /tmp/nikal-2.6.18.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -uNr ni488-kmod-2.5.1-orig/bin/installerUtility.sh ni488-kmod-2.5.1-2.6.18/bin/installerUtility.sh
|--- ni488-kmod-2.5.1-orig/bin/installerUtility.sh      2007-03-05 17:17:41.000000000 +0100
|+++ ni488-kmod-2.5.1-2.6.18/bin/installerUtility.sh    2007-04-13 13:24:30.000000000 +0200
--------------------------
</pre>

I then tried to install the NIKAL 1.5 suggested elsewhere.  The patch failed with:

<pre>
patching file bin/installerUtility.sh
Hunk #1 FAILED at 324.
Hunk #2 succeeded at 343 (offset 10 lines).
1 out of 2 hunks FAILED -- saving rejects to file bin/installerUtility.sh.rej
patching file src/clientKalInterface.c
patching file src/kalInterface.c
patching file src/nikal.c
Hunk #2 FAILED at 86.
Hunk #3 FAILED at 1166.
2 out of 3 hunks FAILED -- saving rejects to file src/nikal.c.rej
</pre>

Any clues for the clueless?

As uneducated as I am, one could argue that these questions are almost off-topic but I would really appreciate a boot in the correct direction.  Once done I will be happy to submit a "cookbook" back to this thread.

[ninevoltz]

This thread does meander quite a bit. I would recommend installing from the nidaq .iso first. After it fails at the end, install the latest NIKAL (National Instruments Kernel Application Layer) and see how that goes. If it fails, look into the patches on this thread, there is also a patch for the 2.6.20 kernel (I haven't tried it, so I personally can't say if it works). The NIDAQ iso file contains the entire driver package and the seperate NIKAL is to provide compatibility with later kernel versions.

Patches are easy to deal with when you understand the command line wrangling.

Inside the patch there are lines that specify the path and filename of the original and the modified file. Using a command like patch -p0 < mypatch.patch
will use the entire path from each line (starting from your present location on the command line), so if a part of that path does not exist on your system, it will fail (i.e. HUNK xxx failed). using a line like patch -p2 < mypatch.patch
will strip off the first two (-p2) directory names leaving the rest intact. It's also important that the patch exactly matches the source file you intend to patch. Check the line numbers in the patch and compare them to your source file to make sure they will match. A plus sign at the start of a line means the line will be added, a minus means removed. A good application for viewing patch files is kompare for KDE, it gives a fantastic graphical view of each change.

As far as writing a cookbook, I would recommend starting an entirely new thread for that, because this one is now clearly getting hard to follow, and the new NIKAL versions may fix a lot of the problems addressed here.

Good luck, and let us know if you still need help.

John

[JHn]

JohanNavra...,

The patches that I attached in my post is for NIKAL 1.4. I think that the NIKAL version in 'NIDAQ800_RedHat.iso' is 1.3. The changes that NI have made in NIKAL 1.5 does not address the issues with kernel 2.6.19 and 2.6.20 (which my patches does). If you dowload NIKAL 1.4 from the same place where you found NIKAL 1.5, you could use my patches

Sorry if I was a bit unclear about this in my post 🙂

[JohnNavratil]

The attachment contains JHn's patches modified for NIKAL1.5.  This was done by inspection, not testing, but does result in a successful compile of nikal.c.  This was done on a 2.6.20 kernel source tree and, while the patches were applied in sequence, the intermediate code was NOT compiled on .18 or .19 kernels.  Perhaps JHn could review my effort.  Also, I couldn't find NIKAL 1.4 on the site.  If I am successfully building 1.5, does 1.4 help anything?

With the original modpost, I received multiple errors of the form:

make -C /lib/modules/2.6.20-1.2316.fc5/source SUBDIRS=/usr/local/natinst/nikal/src/objects modules
make[1]: Entering directory `/usr/src/kernels/2.6.20-1.2316.fc5-i686'
  CC [M]  /usr/local/natinst/nikal/src/objects/nipxirmk-interfaceFile.o
  CC [M]  /usr/local/natinst/nikal/src/objects/nipxirmk-export.o
  LD [M]  /usr/local/natinst/nikal/src/objects/nipxirmk.o
  Building modules, stage 2.
  MODPOST 1 modules
FATAL: parse error in symbol dump file
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.20-1.2316.fc5-i686'
make: *** [objects/nipxirmk-interfaceFile.ko] Error 2
ERROR: failed to build nipxirmk.ko
 nipxirmk.ko failed to update.

With ninevoltz's modpost, I received floating point exceptions.  I'm off to the "NIDAQmx on Fedora Core 5 How-To" thread, bit if anyone has any quick ideas to solving this, I'm all eyes.

Finally, it appears that I must recompile the kernel to implement an 8K stack, in any event.  Is this correct?  Well, if I must build a kernel in this century, I'd better get started 🙂

[Shawn B.]

---

@JohnNavratil wrote:
Also, I couldn't find NIKAL 1.4 on the site.  If I am successfully building 1.5, does 1.4 help anything?

---

Here is a link to All NI-KAL Versions.  In my opinion you should always use the latest version of NI-KAL since it should require fewer patches, and has been verified on our in house test suite.  For example NI-KAL 1.5 should already work with kernels up to and including 2.6.18 (of course in this case that is openSUSE's 2.6.18).  For this reason I looked at your 2.6.18 patch (which shouldn't be needed) and it looks like the only valid change is the removal of config.h.  Once again in my opinion the removal of config.h is a 2.6.19 change but config.h shouldn't be needed in 2.6.18 either.

---

@JohnNavratil wrote:
Finally, it appears that I must recompile the kernel to implement an 8K stack, in any event.  Is this correct?  Well, if I must build a kernel in this century, I'd better get started 🙂

---

If you are using NI-DAQmx, NI-SCOPE, NI-DMM, or NI-FGEN, then I would say to be safe you should recompile your kernel with an 8K stack.  Of course it really depends on what hardware you are using, and how you happen to be using the API.  If you are lazy, or willing to experiment (you may be since you are patching NI-KAL), you could always try using the kernel with a 4K stack and and hope that your use case doesn't cause the machine to Oops, Panic, or otherwise lockup.  If it does then you should probably recompile the kernel with a 8K stack.

Shawn Bohrer
National Instruments

[ninevoltz]

Make sure you have kernel-devel and kernel-headers installed for your kernel version, then cd to /usr/src/kernels/2.6.20.xxx/ and do a make. Make will fail almost immediately, but it will go just far enough to rebuild modpost for you. Neat trick, huh? Just modify the modpost source first in /usr/src/kernels/2.6.20.xxxx/scripts/mod/modpost.c by changing the line #define SZ 500 to #define SZ 1024 (it was line # 1113 on 2.6.20-1.2948. This is what cause symbol parse errors, the buffer is too small for the _huge_ export names in NIKAL.

[ninevoltz]

I'm running it NIDAQmx now with 4k stacks and it seems to be fine, I'm using it with a PCI-6514 and PCI-6221.

[JHn]

---

@JohnNavratil wrote:
The attachment contains JHn's patches modified for NIKAL1.5.  This was done by inspection, not testing, but does result in a successful compile of nikal.c.  This was done on a 2.6.20 kernel source tree and, while the patches were applied in sequence, the intermediate code was NOT compiled on .18 or .19 kernels.  Perhaps JHn could review my effort.  Also, I couldn't find NIKAL 1.4 on the site.  If I am successfully building 1.5, does 1.4 help anything?

---

Good to hear that the patches helped you on the way! I just had a quick look at your modification and it looks like you only made small changes. If it compiles, I say its good to use My patches are written in such a way that you could compile nikal for 2.6.18 even after you have applied the 2.6.20 patch. I choose to do so just to show that it is actually possible to have one codebase that compiles on many kernels. In a longer run, this is of course not a good way to go.

I don't see any reason for you to use NIKAL 1.4 now that you have converted the patches to 1.5! You can find version 1.4 here if you are intrested: ftp://ftp.ni.com/support/kal/1.4.

---

With the original modpost, I received multiple errors of the form:

make -C /lib/modules/2.6.20-1.2316.fc5/source SUBDIRS=/usr/local/natinst/nikal/src/objects modules
make[1]: Entering directory `/usr/src/kernels/2.6.20-1.2316.fc5-i686'
  CC [M]  /usr/local/natinst/nikal/src/objects/nipxirmk-interfaceFile.o
  CC [M]  /usr/local/natinst/nikal/src/objects/nipxirmk-export.o
  LD [M]  /usr/local/natinst/nikal/src/objects/nipxirmk.o
  Building modules, stage 2.
  MODPOST 1 modules
FATAL: parse error in symbol dump file
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.20-1.2316.fc5-i686'
make: *** [objects/nipxirmk-interfaceFile.ko] Error 2
ERROR: failed to build nipxirmk.ko
 nipxirmk.ko failed to update.

With ninevoltz's modpost, I received floating point exceptions.  I'm off to the "NIDAQmx on Fedora Core 5 How-To" thread, bit if anyone has any quick ideas to solving this, I'm all eyes.

Finally, it appears that I must recompile the kernel to implement an 8K stack, in any event.  Is this correct?  Well, if I must build a kernel in this century, I'd better get started 🙂

---

I haven't seen the modpost problem with the GPIB driver and now I understand why; It is apparently a result of the DAQ specific binary only blobs that is linked in with the kal interface. Binary only blobs are not a good thing in an evolving kernel... hint hint NI

I can't comment on the 8k stack issue since I think that the GPIB driver is not affected by this (hope I'm not wrong because beeing forced to recompile the kernel is not an option for me...).

[JohnNavratil]

As promised, I collected my notes and started a new thread.

Fedora Core 5 - kernel 2.6.20 -NIKAL 1.5 howto