Fedora Core 6 How-to

[ninevoltz]

Here's a new, much easier and faster, mini how-to for installing NIDAQmx on Fedora Core 6. No kernel rebuilding required.

Step 1. Download the file NIDAQ800_RedHat.iso from ni.com

Step 2. Mount the iso file from a command line: mount -t iso9660 /path/to/iso /mnt/iso -o loop

Step 3. Create a symbolic link to asm-offsets.h: ln -s /lib/modules/$(uname -r)/source/include/asm/asm-offsets.h /lib/modules/$(uname -r)/source/include/asm/asm_offsets.h

Step 4. Open /lib/modules/$(uname -r)/source/include/linux/utsrelease.h and copy the line #define UTS_RELEASE "2.6.xx-1.xxxx.fc6", paste it into /lib/modules/$(uname -r)/source/include/linux/version.h, and then save it.

Step 5. Run /mnt/iso/INSTALL use the default installation paths for everything.

Step 6. When INSTALL finishes, don't reboot. Instead run: patch -p0 < nikal.patch using the file attached to this post.

Step 7. Copy the modprobe file from the file attached to this post to /lib/modules/$(uname -r)/source/scripts/mod/
I submitted a bug report for modprobe to the kernel.org site in regard to this, hopefully it will get fixed sometime in the future.

Step 8. Run updateNIDrivers and reboot.

[ninevoltz]

The powers that be at kernel.org have decided that modpost should not be allowed to accept symbols larger than 500 characters, so it will not be changed. I would suggest that if anyone at NI is listening, in the future you guys should shorten your module names or break them up into seperate modules.

[Elijah_K]

I encourage you to enter this information in our product feedback page.  We really do take customer feedback seriously.  Visit ni.com/contact

[ninevoltz]

I've got some new information on the subject of the modprobe error. Apparently Andrew Morton, the kernel maintainer took me seriously and looked into a fix. He wrote a patch then later I got an email saying that the patch was obsoleted with the latest kernel release, so I'm assuming that some other change in kernel 2.6.20 may fix it (or he had a change of heart). I haven't had a chance to test the new kernel with NIDAQ yet though, so I don't know if this is true. At least somebody was paying attention high up in the food chain though. It amazes me though how some people in the kernel dev community don't really seem to give a crap if the users are being taken care of. The immediate response to my bug was from some ass at Oracle stating that "maybe we should make modprobe accept longer and longer symbol hashes everytime somebody makes a longer module entry name" then he invalidated my bug. Snide bastard. Now I know why I won't be using any of Oracle's crap. I hope they support their paying customers better than that.

[Scott314]

Thank you for posting this.  It worked perfectly for me with a fresh FC6 install running kernel 2.6.19-1.2911.6.5.fc6.

Scott

[ninevoltz]

Modpost is fixed in the 2.6.20 kernel, so the modpost error will not be a problem anymore. I think Andrew Morton's idea was to make modpost dynamically resize the buffer for the module names, so it's fixed now.

[ninevoltz]

I was mistaken, it's not fixed. I upgraded recently and forgot that I didn't run updateNIDrivers yet.

Modprobe is broken still and now there is a new problem, the kernel workqueue code was changed so that INIT_WORK now only requires 2 parameters instead of three. I'm going to try fixing it tomorrow, but I'm not confident that I will get it to work, mostly because I have no idea what the hell the workqueue even is...

I'll be back with a patch for nikal.c if I succeed, otherwise I'll be rolling back to 2.6.19 (or whatever).

[ninevoltz]

What a mess! I'd like to thank the kernel developers for creating a royal pain-in-the-ass with kernel 2.6.20.

I'm going to roll back my kernel tomorrow. It's going to be up to National Instruments to fix this one. Oh, and I would also like to extend thanks to the National Instruments driver developers for not putting one single comment in 4000+ lines of code. What a bunch of crap. We'll be looking for a different vendor when we need new DAQ equipment.

Here's a tip for the NI developers on how to move past kernel 2.6.20 (as if they actually gave a crap about supporting Linux in the future😞 work_struct reduction

I also started a patch for the Kernel Abstraction Layer code (NIKAL) and it is attached, it will compile using updateNIDrivers, but will crash when you attempt to run DAQ. Not sure what I did wrong, but without comments in the code, I don't forsee ever figuring it out. I don't really care at this point anyway.

[Elijah_K]

Whew, this certainly has become quite an ordeal.  I empathize with your frustration and I wanted to let you know that your feedback has been passed along to engineers within our R&D department.

We definitely support our hardware with Linux, but we only officially support RHEL 4, RHEL 3, Mandriva and SUSE.  We do have developers focused on the use of our products with Linux, but I'm afraid that we cannot guarantee compatibility with Fedora.

If any members of the community continue the work with NIKAL I strongly encourage you to post your progress on this thread.  Thanks!

[ninevoltz]

I apologize if I appeared hot-headed in my last post, but a long day of unsuccessful debugging tends to have that effect on me. It was probably a little bit drastic to threaten to switch vendors too, but it sucks that there isn't any comments or documentation for the NIKAL code.

I realize that NI does not support Fedora, and I don't expect you guys to, but it would be nice if there was some detailed info on how this NIKAL layer works.  

And for the record, kernel 2.6.20 has a couple of other unrelated issues that also make it not worth the upgrade, but I know this problem with NIKAL will be here to stay.