Fedora Core 6 How-to

[ninevoltz]

You cannot use NIDAQmx with kernel 2.6.20, it will take major modifications to fix the work queue. If any kernel hackers out there ever manage to fix it, let us all know. Otherwise, I would suggest rolling your kernel back to the latest 2.6.19.  I've seen some other networking problems with the 2.6.20 kernel, so you might not want to use it anyway.

[JHn]

I'm not using NIDAQmx myself but the NI488.2 v2.5 Linux driver (dowloaded the .iso from NI) for a GPIB-PCI card. As I understand it, the problematic part for all of us is the nikal kernel module (with build scripts) and that is shared with NIDAQmx.

I have successfully used the driver with Fedora Core 6 with kernels 2.6.18, 2.6.19 and 2.6.20. The fix for the work queue changes in 2.6.20 took some time, but it was not impossible. I have a set of patches that probably overlap a bit with ninevoltz original patch but I will try to put together a description of what I did and post here soon (with patches).

[JHn]

Hmm, when I read the thread more carefully I noted that the driver in question is the older NIDAQ800_Redhat.iso. I don't know what version of nikal is in that driver but in the "nidaqmxbase-2.1.0.iso"-driver the nikal version is the same as in the latest GPIB driver. So, the fix that I have for the nikal part in the GPIB driver might only work with the latest NIDAQmx-base. Anyway, here is how I fixed the GPIB driver to work with Fedora Core 6 kernels from 2.6.18 up to (and including) 2.6.20:

Disclamer: I'm not a kernel guru and I *might* hav missed some important aspect of the work queue concept, but the fix described below have worked for me!

The description assumes that you have an installed and unmodified NIDAQmx-base driver. If you have patched the nikal c-files with ninevoltz patches you have to restore the original files! Also, it is probably a good idea to make a backup of the /usr/local/natinst/nikal directory before you start 🙂

1. Dowload the three attached patches to /tmp
2. Run the following commands (as root):
    # cd /usr/local/natinst/nikal
    # patch -p1 < /tmp/nikal-2.6.18.patch
    # patch -p1 < /tmp/nikal-2.6.19.patch
    # patch -p1 < /tmp/nikal-2.6.20.patch
3. Now, updateNIDrivers should hopefully work

I have not myself had any problems with modpost as reported in this thread so I can't comment on that. It would be intresting to hear from anyone that succeeds with these patches!

Good luck!

[tbird]

Hi,

I'm trying to do the basic install of NI-488.2 version 2.5 on a Fedora Core 6 system with kernel 2.6.18-1.2798.  I keep getting the messasge:


******************************** ERROR ****************************************
* Kernel source in /lib/modules/2.6.18-1.2798.fc6/source does not appear to be
* for the 2.6.18-1.2798.fc6 kernel.
* Ensure that kernel source for the 2.6.18-1.2798.fc6 kernel is installed
* and configured.  Refer to the README file for the product you are           *
* installing for information about configuring your kernel source.            *
******************************** ERROR ****************************************


I get this even though it is the correct version.  I have installed the headers and sources and I can  recompile the kernel with no problem.

I've seen references to this problem for other flavors of Linux but not for FC 6.  Any hints how to get this working?


Thanks!

Rick

[Hubert G]

Hi Rick

You have to define the UTS_REALEASE constant in the file version.h
as root :
cd /usr/src/linux/include/linux/
mv version.h version.h.orig
cat utsrelease.h version.h.orig > version.h

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><meta name="GENERATOR" content="OpenOffice.org 2.2 (Linux)"><meta name="AUTHOR" content="glasson"><meta name="CREATED" content="20070402;17280000"><meta name="CHANGEDBY" content="Hubert Glasson"><meta name="CHANGED" content="20070522;17351900"><meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><meta name="GENERATOR" content="OpenOffice.org 2.2 (Linux)"><meta name="AUTHOR" content="glasson"><meta name="CREATED" content="20070402;17280000"><meta name="CHANGEDBY" content="Hubert Glasson"><meta name="CHANGED" content="20070522;17351900">You also have to make a symbolic link to usr/src/linux/include/asm/asm-offsets.h called asm_offsets.h (in the same dir)
as root :
ln -s /usr/src/linux/include/asm/asm-offsets.h /usr/src/linux/include/asm/asm_offsets.h

then try again the installation

Hubert

[tbird]

Hi Hubert,

Thanks!  That saved many hours of hair-pulling.

In addition the nikal-2.6.xx.patch listed above is also necessary.

Rick

---------------------

Hi Rick

You have to define the UTS_REALEASE constant in the file version.h
as root :
cd /usr/src/linux/include/linux/
mv version.h version.h.orig
cat utsrelease.h version.h.orig > version.h

You also have to make a symbolic link to usr/src/linux/include/asm/asm-offsets.h called asm_offsets.h (in the same dir)
as root :
ln -s /usr/src/linux/include/asm/asm-offsets.h /usr/src/linux/include/asm/asm_offsets.h

then try again the installation

Hubert

[JHn]

Hi!

The nikal-2.6.18.patch in my previous post fixes the script in nikal so that the script also checks for the UTS_RELEASE define in utsrelease.h (where it is nowdays). So, after you patched nikal with nikal-2.6.18.patch you don't need to manually add the UTS_RELEASE define to version.h anymore. This could be good to know when you upgrade your kernel to a newer release.

But: when you install the driver for the first time, it is necessary to modify version.h as described in this thread.

Also, I didn't need to create the asm_offset.h soft link to make nikal compile. Is this really necessary for kernel 2.6.18 and above, or is it something that belongs to some other distribution fixes??

[ninevoltz]

I think if you use NIKAL 1.3 the asm_offsets.h problem is fixed in there.
 

[JHn]

---

@ninevoltz wrote:
I think if you use NIKAL 1.3 the asm_offsets.h problem is fixed in there.
 

---

The GPIB driver that I use have NIKAL 1.4 in it. Apperantly there are no "asm_offset.h"-problem with this version. Thanks for clarifying this for me!

[Shawn B.]

Wow, it has been a while since I looked at this thread, but I figure I should post and answer some questions (then I can get notifications too!).  First I just wanted to say that you guys are doing an awesome job!  As many of you have noticed nearly each new kernel version requires updates to the NI-KAL component.  It seems what you may not have noticed is that NI-KAL is available seperately on the web:

http://digital.ni.com/softlib.nsf/webcategories/86256C220055D6BC86256BE6007086A2?opendocument&node=1...

I would highley recommend installing the latest version of NI-KAL before making modifications because it may already fix your problems.  We don't release NI-KAL as frequently as the mainline kernel, but we try to have a new version available shortly after each new version of one of our officially supported distributions (RHEL, Mandriva, and openSUSE) releases.

RHEL WS 5 support was mentioned.  If you read my statement above, you could probably guess that there will be a new version of NI-KAL that officially support RHEL WS 5.  While you are waiting though I would recommend trying NI-KAL 1.5 since it supports openSUSE 10.2 (has a 2.6.18 kernel and so does RHEL WS 5).  I should also mention that RHEL WS 5 has a 4k kernel stack just like RHEL WS 4 and the Fedora Cores which means that some of our drivers like NI-DAQmx 8.0 can overflow the stack and cause the machine to crash (depending on your hardware and usage).

Shawn Bohrer
National Instruments