NIDAQmx on Fedora Core 5 How-To

[ninevoltz]

Here is my how-to I promised for installing DAQmx on Redhat Fedora Core 5.

Also attached are modified kernel and ramdisk for anyone who wants to save the compiling time and trouble.

John

[Shawn B.]

Thanks for the How-To John!

Just to make things simpler:

Step 3.5) Install the latest version of NI-KAL (Currently 1.3)

Step 5) NI-DAQmx installed successfully!

Shawn B.
National Instruments

Message Edited by Shawn B. on 07-31-2006 04:40 PM

[ninevoltz]

I did a "yum update" yesterday, installed kernel 2.6.17-1.2157_FC5. So I downloaded the kernel source, recompiled for 8Kb stacks, installed the new kernel and rebooted.

Now I tried to reinstall NIDAQmx. I used the NIKAL 1.3 package on top of the normal NIDAQ 8.0.

Build failed because of a race condition bug that was fixed in this kernel release, so to fix it line number 87 has to be changed to:
#define put_page_testzero(p)   atomic_dec_and_test(&(p)->_count)

Now it builds and updates ok, but this problem pops up when the modules are attempting to be installed:

make -C /lib/modules/2.6.17-1.2157_FC5/source SUBDIRS=/usr/local/natinst/nikal/src/objects modules
make[1]: Entering directory `/usr/src/redhat/BUILD/kernel-2.6.17/linux-2.6.17.i686'
  CC [M]  /usr/local/natinst/nikal/src/objects/nisftk-interfaceFile.o
  CC [M]  /usr/local/natinst/nikal/src/objects/nisftk-export.o
  LD [M]  /usr/local/natinst/nikal/src/objects/nisftk.o
  Building modules, stage 2.
  MODPOST
FATAL: parse error in symbol dump file

etc... etc...same stuff...

Help! I don't understand what this means.

John

[ninevoltz]

Ok, I figured out a workaround for NIDAQmx on kernel 2.6.17-1.2157_FC5 and got it working again. (Why don't the NI folks keep up with the new kernels? Why do customers have to figure out why their software doesn't work? Argghh!)

Before doing a "make" to build your modified kernel, edit this file:

/usr/src/linux/scripts/mod/modpost.c

change the "fail" routine at line number 1187 to:

fail:
    return; //fatal("parse error in symbol dump file\n");

This will keep updateNIDrivers from failing. The new modpost doesn't seem to like nidaq. Doesn't seem to be a big deal.
I would change the modpost file back to its original code after successfully installing nidaq.

Last but not least, change line 87 of /usr/local/natinst/nikal/src/nikal.c to:

#define put_page_testzero(p)   atomic_dec_and_test(&(p)->_count)

This was a bugfix in the new kernel to prevent a race condition.

John

[Jarrod_B.]

Hello ninevoltz,

Thanks for sharing this information with the community.  To answer your question ("Why don't the NI folks keep up with the new kernels?"), because Linux is open source, kernel and distribution updates come out at a frantic pace.  This makes it unrealistic for us to be able to keep every driver constantly updated for all the new releases. 

In NI-DAQmx Version 8.0 for Linux, we support the following distributions:

• Mandrakelinux 10.1 Official and Mandriva Linux 2006
• SUSE LINUX Professional 9.2 and 9.3
• Red Hat Enterprise Linux WS 3

These are the only distributions for which we can guarantee that our driver will install and work properly.  Thanks to the information that you have provided, other users will have some insight into how to use NI-DAQmx 8.0 on Fedora Core 5.  Thanks again for posting your solution!

Best regards,

[ninevoltz]

What happens when an Enterprise Workstation user upgrades his kernel? Do the drivers still magically work somehow? Will NI support that? Or is it even possible to upgrade your kernel in EW (I'm not familiar with it)?

John

[Shawn B.]

Red Hat Enterprise WS, SUSE, and Mandriva will all provide security updates to their kernels, but they generally do not change kernel versions.  In other words when SUSE releases with 2.6.16-xx, they will apply security patches and release something like 2.6.16-xy, but they won't release something like 2.6.17-xx, which is usually where things break.

Fedora as you may know provides the latest kernels as they are released, which is very hard for us to keep up with.  In our defense NI-KAL 1.3 should compile on kernels up to 2.6.16 so we are only one kernel version behind.  As new versions of NI-KAL are released (which will be more frequent than NI-DAQmx), we will try to at least ensure we compile on the latest kernels (though we can only support the distributions listed in the README).

I do appreciate your posts on the forums!

Shawn B.
National Instruments

[ninevoltz]

"yum update" this morning believe it or not, provided yet another new kernel release! So I tested NIDAQ on version 2.6.17-1.2174_FC5 (apparently just released yesterday) and it is still working with the fixes I posted earlier.  I may have to create a script to speed up the process if the kernel releases keep coming out so often...

I see now how it would be hard for you guys at NI to keep up with these releases....

John

[ninevoltz]

Just for a follow-up, the NI drivers are tested and worked with Fedora Core 5 kernel 2.6.17-1.2187_FC5 using the same methods I wrote up in this thread earlier.

[ninevoltz]

The future does not look good for NIDAQmx on Fedora Core 5, the modules will not load on the latest kernel (2.6.18-1.2200.fc5) , and there are some build messages that hint at why.

include/linux/config.h:6:2: warning: #warning Including config.h is deprecated.
  Building modules, stage 2.
  MODPOST
WARNING: modpost: GPL-incompatible module nikal.ko uses future GPL-only symbol 'usb_deregister'
WARNING: modpost: GPL-incompatible module nikal.ko uses future GPL-only symbol 'usb_register_driver'

There is a new build error in nikal.c too. I just removed VM_SHM from line 1150 and it compiles ok.

l/usr/local/natinst/nikal/src/objects/nikal.c:1150: error: ‘VM_SHM’ undeclared (first use in this function)