VXI drivers on Fedora Core 5?

[CXROGuy]

We just purchased the Linux VXI drivers with assurances that they would work on 2.6 kernels.  We have been moving as many systems as we can to Fedora Core 5 and would like to do the same for our various VXI systems.  So, I tried installing on Fedora Core 5 and got this output:

make -C /lib/modules/2.6.18-1.2257.fc5smp/build SUBDIRS=/u0/local/nivxi/src KBUILD_VERBOSE=0 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-1.2257.fc5-smp-i686'
  CC [M]  /u0/local/nivxi/src/vxi.o
In file included from /u0/local/nivxi/src/vxi.c:13:
/u0/local/nivxi/src/mutex.h:59:42: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
In file included from /u0/local/nivxi/src/vxi.c:13:
/u0/local/nivxi/src/mutex.h:59: warning: \u2018regparm\u2019 attribute only applies to function types
/u0/local/nivxi/src/mutex.h:59: warning: \u2018cdecl\u2019 attribute only applies to function types
/u0/local/nivxi/src/mutex.h:61:42: error: macro "mutex_release" requires 3 arguments, but only 1 given
/u0/local/nivxi/src/mutex.h:61: warning: \u2018regparm\u2019 attribute only applies to function types
/u0/local/nivxi/src/mutex.h:61: warning: \u2018cdecl\u2019 attribute only applies to function types
/u0/local/nivxi/src/vxi.c:128:31: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
/u0/local/nivxi/src/vxi.c:133:31: error: macro "mutex_release" requires 3 arguments, but only 1 given
/u0/local/nivxi/src/vxi.c:146:31: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
/u0/local/nivxi/src/vxi.c:158:31: error: macro "mutex_release" requires 3 arguments, but only 1 given
make[2]: *** [/u0/local/nivxi/src/vxi.o] Error 1
make[1]: *** [_module_/u0/local/nivxi/src] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-1.2257.fc5-smp-i686'
make: *** [default] Error 2

This appears to be a kernel incompatibility problem.  Anybody have any hints about how to compile the driver on Fedora Core 5?  Or, is NI planning to support these newer kernels?  If not, will I be able to use FC 4, or do I have to go back further?

Thanks.

[Anna_M]

HI CXROGuy,

You may be interested in this post.  It has instructions for installing NI-DAQmx on Fedora Core 5 with NI-KAL 1.3 for 2.6 version kernals.  Hope this helps!

[CXROGuy]

Thanks for the reply Anna S.  I tried following the referenced howto up through step 11 (i.e. building a kernel), but got the same errors when building the vxi kernel module.  The steps for building the kernel were the same even though I am using version 2.6.18.2257 rather than the 2.6.15-2054 kernel in the howto; I don't know if the kernel version makes a difference in this case.  My next step will be to try stepping back to the 2.6.15 version.

In the meantime, and not wishing to appear to be throwing a problem out there without at least trying to find a solution, I tried hacking the source code included with the nivxi driver, replacing all declarations and references to mutex_* functions with nimutex_*.  (I also had to replace a call to __put_page with put_page)  That enabled me to compile the driver, though it gave warnings about missing mutex_* functions.  That's not surprising since there are a couple of object files included for which the source code is not included; what is surprising is that it compiled and linked at all.  Anyway, once that was done, I tried /usr/local/nivxi/sys/load_vxi, and it complained about a missing function definition and choked.  Again, not surprising since I don't have all the source code to hack away at.

I think the question here is more basic than that though: how is it that you can define mutex_* functions without conflicting with the operating system?  Are they not defined in the kernels for the supported distributions (unlikely)?  Or is a header file being included that shouldn't be?  Or ...?

Any help would be greatly appreciated.

[CXROGuy]

The conflict with mutex_* methods disappeared when I switched to a non-SMP kernel.  There was still a conflict in the struct mutex type, but renaming it to 'struct nimutex' in mutex.c, and changing 'typedef mutex * mutex_t' to 'typedef nimutex * mutex_t' fixed that, the module compiled and runs.  Not sure why that change was necessary, but I only really care about making this thing work.

Thanks again for the help.  A suggestion: how about detecting a SMP kernel when installing, and providing feedback to the user that SMP kernels won't work?  This is going to be a more common problem with the adoption of multicore processors.

[Anna_M]

Hi CXROGuy,

That sounds like a good suggestion, and you can actually submit product suggestions to our R&D department through this website.  I'll submit one as well!

[CXROGuy]

Anna S.,
Good idea; will do.  Thanks!

[mdsaero]

I had the following error messages when building the VXI driver on Vanilla 2.6.19, I saw the posting that the problem is gone when the kernel is non-SMP, but we need the SMP because our system is Dell 2950 with two Xeon dual-core processors, can someone or NI help us to resolve the problem?

Thanks,

Huaqing

make -C /lib/modules/2.6.19.1-rt15/build SUBDIRS=/usr/local/nivxi.new/src KBUILD_VERBOSE=0 modules
make[1]: Entering directory `/usr/src/linux-2.6.19'
  CC [M]  /usr/local/nivxi.new/src/vxi.o
In file included from /usr/local/nivxi.new/src/vxi.c:13:
/usr/local/nivxi.new/src/mutex.h:59:42: macro "mutex_acquire" requires 4 arguments, but only 1 given
In file included from /usr/local/nivxi.new/src/vxi.c:13:
/usr/local/nivxi.new/src/mutex.h:59: warning: `regparm' attribute only applies to function types
/usr/local/nivxi.new/src/mutex.h:59: warning: `cdecl' attribute only applies to function types
/usr/local/nivxi.new/src/mutex.h:61:42: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi.new/src/mutex.h:61: warning: `regparm' attribute only applies to function types
/usr/local/nivxi.new/src/mutex.h:61: warning: `cdecl' attribute only applies to function types
/usr/local/nivxi.new/src/vxi.c: In function `vxi_install_interrupt_handler':
/usr/local/nivxi.new/src/vxi.c:112: warning: passing arg 2 of `request_irq' from incompatible pointer type
/usr/local/nivxi.new/src/vxi.c:128:31: macro "mutex_acquire" requires 4 arguments, but only 1 given
/usr/local/nivxi.new/src/vxi.c:133:31: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi.new/src/vxi.c:146:31: macro "mutex_acquire" requires 4 arguments, but only 1 given
/usr/local/nivxi.new/src/vxi.c:158:31: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi.new/src/vxi.c: At top level:
/usr/local/nivxi.new/src/mutex.h:59: error: storage size of `mutex_acquire' isn't known
/usr/local/nivxi.new/src/mutex.h:61: error: storage size of `mutex_release' isn't known
make[2]: *** [/usr/local/nivxi.new/src/vxi.o] Error 1
make[1]: *** [_module_/usr/local/nivxi.new/src] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.19'
make: *** [default] Error 2

[Sarah_R]

mdsaero,

I have found a related KnowledgeBase: NI-VXI for Linux Hangs on SMP/Hyperthreaded Machines with APIC Enabled that I think may apply to the error you are currently seeing. I am not sure if you have seen this or not and would recommend giving this a try.

Please let me know if this is able to alter the behavior you are seeing in anyway.

[mdsaero]

Thanks.

That case actually was raised by me before which fixed the freeze issue on SMP kernel 2.6.16 running on Dell PowerEdge 2850, but the Dell PowerEdge 2850 is now discontinued, so we are now using the PowerEdge 2950, but could not runing 2.6.16, we have to run kernel 2.6.19, it seems there are some differences between 2.6.16 and 2.6.19 on mutex, I am still trying to resolve the problem, now I can build the driver, but there are still a few warnings, like below:

make -C /lib/modules/2.6.19.1-rt15/build SUBDIRS=/usr/local/nivxi/src KBUILD_VERBOSE=0 modules
make[1]: Entering directory `/usr/src/linux-2.6.19'
  CC [M]  /usr/local/nivxi/src/vxi.o
/usr/local/nivxi/src/vxi.c: In function `vxi_install_interrupt_handler':
/usr/local/nivxi/src/vxi.c:112: warning: passing arg 2 of `request_irq' from incompatible pointer type
  CC [M]  /usr/local/nivxi/src/vxi_kernel.o
  CC [M]  /usr/local/nivxi/src/pci_io.o
  CC [M]  /usr/local/nivxi/src/mutex.o
  CC [M]  /usr/local/nivxi/src/vxiTimer.o
  LD [M]  /usr/local/nivxi/src/vximod.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "mutex_acquire" [/usr/local/nivxi/src/vximod.ko] undefined!
WARNING: "mutex_release" [/usr/local/nivxi/src/vximod.ko] undefined!
  CC      /usr/local/nivxi/src/vximod.mod.o
  LD [M]  /usr/local/nivxi/src/vximod.ko
make[1]: Leaving directory `/usr/src/linux-2.6.19'
Kernel module built successfully and placed in ../sys/
Use /usr/local/nivxi/src/../sys/load_vxi to load it.

[mdsaero]

To resolve the problem, the following changes should be made:

1) Replace the __put_page(pg) to atomic_dec(&(pg)->_count)

2) Replace the second argument of request_irq function to (irq_handler_t)vxi_tophalf

3) Replace all <asm/semaphore.h> to <linux/semaphore.h>

4) Replace all struct semaphore to struct compat_semaphore

5) Replace struct mutex to struct mutex_NI

5) The 2.6.19 introduced a new linux/lockdep.h which defined mutex_acquire and mutex_release which conflict with mutex.h, the easiest way is to comment the two macros in the linux/lockdep.h. The other way is to modify the VXI driver source to use different function names for mutex_acquire and mutex_release, then we need source code to recompile nivxi.o and dmamgr.o.

Huaqing