NIDAQmx on Fedora 9

[ninevoltz]

Here's a patch for NIKAL 1.7 (NIDAQmx 3.1) to use with kernel 2.6.25.

You still have to modify modpost.c in the kernel source to allow for the enormous symbol names in nikal.

John

[death]

Hi

After a brief period of not using NI boards, I needed to run on F9. This is just a quick note to say that you don't need to recompile the whole kernel to get modpost. Just tell make to keep going (use the -k flag)

yum install kernel-headers kernel-devel
cd /usr/src/kernels/$(uname -r)
sed -i "s/#define SZ 500/#define SZ 1024/" scripts/mod/modpost.c
make -k modules_prepare

Then you still need the version patch...

cd include/linux/
mv version.h version.h.orig
cat utsrelease.h version.h.orig > version.h
cd ../asm/
ln -s asm-offsets.h asm_offsets.h

add ninevoltz's nikal patch and run

updateNIdrivers

[JohnNavratil]

Back after a year of playing with a PCI-6221 on Fedora 7, I have a new project using a PCI-6224 on Fedora 9.  I installed NIKAL1.8 and took a look at the 1.7 patch with an eye to converting it to 1.8.  The only apparent effect of the patch was to add "pciDriver->enable_wake = NULL;" as it appeared that NI has added code to properly define IRQF_DISABLED and IRQF_SHARED if they are not present.  (The patch also changed the license to GPL).

However, there is no longer a structure element named 'enable_wake'.  So I backed out the patch, ran updateNIDrivers and rebooted, whereupon 'nilsdev --verbose' reported seeing my PCI-6224 card.  I haven't started any coding and I still need to straighten out libOSMesa.so.4 on this new machine before the test panels will run, but could it be that patching is no longer needed?

Looking over the utility.sh script it appears NI is looking for 'utsrelease.h' as well as 'asm-offsets.h' so manipulations of these source files appears redundant.  I backed out these changes and updateNIDrivers seemed to work fine.  I assume the '#define SZ 1024' patch to modpost.c is still required, but was unsure how to back out the change to test this.

As it stands, it appears the procedure to get NIKAL 1.8 onto Fedora 9, kernel 2.6.25 is...

Download NIDAQ800_RedHat.iso (NI-DAQmx 8.0) from http://joule.ni.com/nidu/cds/view/p/id/375/lang/en, and NIKAL18.iso from http://joule.ni.com/nidu/cds/view/p/id/1075/lang/en.  Install kernel-devel and kernel-headers packages.

cd /usr/src/kernels/$(uname -r)
sed -i "s/#define SZ 500/#define SZ 1024/" scripts/mod/modpost.c
make -k modules_prepare

mount -o loop <path-to-iso>/NIDAQ800_RedHat.iso /mnt
cd /mnt
./INSTALL
<< Accepted license, installed without LabView and did not reboot. >>
umount /mnt

mount -o loop <path-to-iso>/NIKAL18.iso /mnt
cd /mnt
./INSTALL
<< Accepted license, took default installation point. >>
umount /mnt

cd /usr/local/natinst
updateNIDrivers
<< Accepted generous offer to reboot>>

nilsdev --verbose

<< Successfully reports PCI-6224 as dev1 >>

DISCLAIMER:  I discovered this after mucking about with a pristine system.  If I were really worth anything, at all, I would test all this on a fresh build of a machine.  Perhaps later 

Kudos to NI for combing all this out!!!

-- John Navratil

[ninevoltz]

I used Fedora 9 for about a week, then I wiped my drive and went back to Fedora 8. Fedora 9 (KDE 4.x specifically) is horrible. My system kept freezing up, the majority of the KDE 4 apps are incomplete or unstable. Fedora 9 should have never been released to the general public. I wouldn't recommend using it if you value system stability.

John 

[JohnNavratil]

Your Fedora 9 cautionary tale is not without merit.  This is my fourth try with it, and this time simply because I was handed a system with F9 on it.  Yesterday morning I would not have considered it, but when I upgraded it I noticed that the repositories had been upgraded from 8.92 to 9.0, the update went smoothly and, so far, I've had no difficulty.

I donate the first pint.  More than that and I am back to Fedora 8.  But as long as it appears stable, I'm willing to keep going.

[JohnNavratil]

To get the test panels working.....

yum install mesa-libOSMesa
ln -s /usr/lib/libOSMesa.so.6.5.3  /usr/lib/libOSMesa.so.4
DAQmxTestPanels
 

[Giopper]

Hi John, Ninevoltz and the others,

I hope you still read this post.

I have two NI-6033E-PCI,  

NIDAQmx 8.0 + NIKAL 1.5 on Fedora 7,

I run a DAQ program I wrote myself under LabVIEW 8.2.

Once in a while the full system freezes,

requiring an hardware reset.

I identified the point where this happens:

it is when I use the "DAQmx AI Start" on the second device.

It happens, on average, only ~1/1000 of the times,

my system must be continuously available, remotely operated

and execute about 10000 start/stop per day, therefore I need

more stability.

I can run exactly the same LabVIEW program under WinXP32,

on exactly the same hardware, it works forever, never seen a crash.

Therefore, my problem is not hardware related, must be due to the

Linux implementation (kernel, NIDAQmx, other modules, ... whatever)

Unfortunately under WinXP the absolute time accuracy is limited

to 15.6 ms, whereas under Linux, using the default LV "Get Time" primitive,

I get ~1 ms accuracy, which is OK for my application.

(to summarize, under Linux good timing but unstable,

under WinXP stable but very bad timing.)

With the hope to get a more stable Linux system,

I am planning to make a new clean installation

switching to Fedora 8 + NIKAL 1.8,

but now I found that you are testing Fedora 9:

what can you say about it?

Did you have stability problems, as reported by Ninevoltz?

Can you suggest Fedora 9 or better I stay on F8?

I have a few more questions.

How do you apply the patch?

Is the patch for NIKAL 1.7 still good for version 1.8?

Do we still need to apply it or you can

confirm that it is no longer needed?

What is the right installation sequence?

First LabVIEW and then NIDAQmx

or the other way around?

Can you say anything about NIDAQmx/LabVIEW under CentOS?

Many thanks for this interesting and very helpful post.

G

[ninevoltz]

I use Fedora 8 with kernel 2.6.24.7 with the 4k stacks option turned OFF. Seems to be stable. I wouldn't recommend Fedora 9 to anyone. I would suggest using CentOS if you want high reliability, and since NI supports the drivers on RHEL, CentOS should be just as good.

[JohnNavratil]

G,

I cannot help with your stability problem, but I will report that I have used a PCI-6221 in Fedora 7 for the last year or more without stability issues.  I am not using LabView nor am I concerned with timing so the comparison is poor, but it is a data point.

I am using Fedora 9 for development at the moment.  As I mentioned earlier I had problems with this distro initially, but currently I am not having any Linux problems with 9.  It seems the birthing pains may have passed. I haven't yet interfaced my PCI-6224 to any equipment so this is a comment on the distro, only.
 
Based on my current experience with 9, I can recommend it particularly as the requirement to patch seems to be reduced to rebuilding modpost.  (Refer to messages 3 and 6 of this thread for details of installation).  I would recommend, however that your first order of business be to test the hardware/OS integration.

Im not using LabView so I won't say with certainty, but I suspect as NIDAQ is the lower level library that you should install is first.  In any case you can perform steps in message 3 and 6, above, to verify that you are talking to your hardware before testing LabView.

I'm unfamiliar with CentOS, sorry.


-- John Navratil