NIDAQmx on Fedora Core 5 How-To

[jbailey]

I am using counter 1 as it has been previously determined through NI that the counter 0 on this card is defective.  That will be repaired when we can get the system working with counter 1.  I believe on counter 1 AUX is pin 46 PFI 11.

I know that Fedora is not supported and to try and rule that out I have installed a new HD into the PC running Red Hat EL WS3.  Everything about the setup is the same except for the HD and the OS.  Once the new OS and NIDAQmx was installed I ran the same program with the same parameters and got the same result.  Under Red Hat there is now a new problem.  I am not able to terminate the example programs once they begin running.  ctrl+c, kill -9, nothing except restarting will work.

At this point it seems like a driver issue.

[jbailey]

Since my problem has strayed a bit off topic from this thread I have started my own here:
http://forums.ni.com/ni/board/message?board.id=250&message.id=26586

[death]

Hi

1st of all thanks John for posting here. Unfortunately I only found this thread while trying to sort out the modpost issue, otherwise I could have saved myself a lot of time... Anyway, just to share a bit here (maybe it will help someone else), when running updateNIDrivers for kernels > 2.6.17, I get an error message that says

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

After searching a bit through updateNIDrivers, I discovered that the problem is that the definition of UTS_RELEASE has been moved from ${kernsource}/include/linux/version.h to ${kernsource}/include/linux/utsrelease.h. Copying the definition back to version.h sorts out the problem. For anyone following the instructions here, the following lines will do that (provided your /usr/src/linux link is OK):

# cd /usr/src/linux/include/linux/
# mv version.h version.h.orig
# cat utsrelease.h version.h.orig > version.h

I'm surprised that you didn't run into this problem - or maybe it's just me 😞

Jacques

[ninevoltz]

Just checking in to report that the DAQmx drivers are still installing and working ok with kernel 2.6.18-1.2868.fc6 on Fedora Core 6. No new surprises.

[Enrico_Segre]

On my turn, checking in to report troubles found in upgrading to Labview 8.20 on Fedora5/kernel 2.6.18-1.2257.fc5. Finally got through with a fair amount of fiddling and thanks to the useful information in this thread. I added my steps  here.
Enrico

[death]

Just updated to FC6 kernel 2.6.19-1.2895. Basically the drivers still work. There is only 1 new issue.

I still need to apply the UTS_RELEASE fix as described above.

The new issue is that include/linux/config.h has gone from the kernel since 2.6.19. Ideally all references to "#include <linux/config.h>" should be removed and everything will work. However there are a buttload of NI source files that reference this header file, so I took the path of least resistance and created a dummy file with the command

# touch /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i686/include/linux/config.h

Jacques

[ninevoltz]

I finally found the cause of the "parse error in symbol dump file" error caused during modpost.

It is a limitation of the modpost program, I have submitted a bug report to the kernel.org bug tracker. It is bug #7878.
http://bugzilla.kernel.org/show_bug.cgi?id=7878

You can read the whole story there.

[ninevoltz]

I just discovered a new problem with the DAQmx 8.0 installer on Fedora Core 6. It looks for UTS_RELEASE in {kernel build dir}/include/linux/version.h.

It's not in there anymore, so you can copy the line from {kernel build dir}/include/linux/utsrelease.h into version.h

Why oh why do the kernel developers do weird stuff like this?

[BrentGold]

Hi, just wanted to thank everyone involved in this thread!!  I don't understand why NI doesn't hire/assign a linux guy to keep up with at least the vanilla kernel releases, especially considering the rather simple changes involved here a college intern could do it, but kudos to NI for at least giving us the source code necessary so that we can do this kind of stuff ourselves!  I had gotten to the modpost problem myself when I discovered this thread. 🙂

The ability to upgrade prevented me from dropping NI cards altogether from our OEM product lines, so its a win for everybody.

[SamVal]

In case anybody runs into this problem with Fedora Core 6, here is the problem and a solution:

 -  I successfully installed NIDAQmx on a machine running Fedora 2.6.18-1.2798  (thanks to all of the invaluable information in this thread!)

 - nilsdev saw my PCIe-6251 with no problems

 - I am not using LabView and was getting an error running DAQMxTestPanels (I thought this was because I didn't have LabView installed because DAQMxTestPanels gives some message about missing some LabView library file -- I didn't realize I needed to install the Mesa graphics libs) 

- I compiled and ran one of the simple ansi_c examples ( AnalogIn/ MeasureVoltage/ Acq-IntlClk) and got this (totally useless) error message:

The software has entered an unknown state - usually as a result of a cascade failure induced by an unexpected series of state inputs. The operation could not be completed as specified and you should immediately terminate all further transactions if you are able to do so.

Status Code: -50150

After hours of flailing and searching the net I ran across a LabView readme that stated there were known problems with LabView and SELinux ( all of you LabView people probably already knew that but I didn't). I figured it was worth a try ( I didn't want SELinux turned on anyway, but I didn't pay attention to the default settings during the install)

So I edited  /etc/sysconfig/selinux to read

SELINUX=disabled 

rebooted, and lo and behold, everything is now working fine!

I hope this helps the next person to run into this problem....