Try to install nidaqmx-8.0.1 on 2.6.16-rt10

[mdsaero]

I had downloaded the nidaqmx-8.0.1f0 package and managed to install all the software into our system, but failed to do the updateNIDrivers. Our system is  running 2.6.16-rt10 which is Vanilla kernel 2.6.16 plus applied the rt10 patch. I attached the niSystemReport.out.gz for the errors when I was doing the updateNIDrivers. Is there anyone using the nidaqmx-8.0.1 on Vanilla 2.6 kernel?

Thanks,

Huaqing Zhan

[Shawn B.]

It looks like your kernel source hasn't been configured.  Depending on what config options you built the kernel with you may be able to do something like:

cd /usr/src/linux-2.6.16

zcat /proc/config.gz > .config

make prepare

updateNIDrivers

Of you may run into additional problems since you are using the RT patches.  I've done a little experimenting with using our products with the RT patches and exerienced some system hangs.  I would recommend you validate your use cases on a non-production system.

Shawn Bohrer

[mdsaero]

Thanks very much.

After the make prepare, it gets better, but it still fails to do the updateNIDrivers. Attached is the new output file generated by the updateNIDrivers.

Huaqing Zhan

[Shawn B.]

You may need to additionally run:

make modules_prepare

Shawn Bohrer

[mdsaero]

It is getting close.

After the make modules_prepare, the nikal.ko is built successfully, I can find the nikal.ko in the directory of /lib/modules/2.6.16-rt10/kernel/natinst/nikal, but the updateNIDrivers still fails with error message. Attached is the new  niSystemReport.out.gz.

Thanks,

Huaqing Zhan

[mdsaero]

It seems all modules are built successfully, but loading the nikal and the nipalk modules fails. Attached file includes the error messages when doing the updateNIDrivers and messages from the dmesg when loading the two modules.

Huaqing Zhan

[Shawn B.]

Well this may be as far as I can help because you are definately running into issues from the RT patches.  I can at least tell you what the errors mean, but I can't tell you a solution.

nikal: Unknown symbol rt_mutex_unlock
nikal: Unknown symbol rt_mutex_trylock
nikal: Unknown symbol __rt_mutex_init
nikal: Unknown symbol rt_mutex_lock_interruptible
nikal: Unknown symbol rt_mutex_lock

These are all functions that NI-KAL needs in order to load but are not exported in the kernel you are running.  This means that either the kernel you are running doesn't have these functions at all or they have have not been exported using the EXPORT_SYMBOL() macro.  For example there should be something like EXPORT_SYMBOL(rt_mutex_unlock) in your kenrel source.  Perhaps these functions use the EXPORT_SYMBOL_GPL() macro instead?

Of course if you look at the source for NI-KAL none of these functions are called directly, which means that they were picked up from the kernel headers.  Since they came from the kernel headers one would think there shouldn't be a problem which makes me think that either a) your kernel source does not match the kernel you are running, or b) these functions use the EXPORT_SYMBOL_GPL() macro.

All of the Unknown symbol errors from nipalk are because nikal.ko failed to load.

Sorry I can't be of more help.

Shawn Bohrer

[mdsaero]

Thanks very much.

You are right. I checked the kernel source code that in the rtmutex.c, it uses EXPORT_SYMBOL_GPL() macro instead of EXPORT_SYMBOL() macro. The rt10 patch modified the rtmutex.c from the original Vanilla kernel source. Can I replace all the EXPORT_SYMBOL_GPL() macro with the EXPORT_SYMBOL() in the rtmutex.c and then rebuild the kernel and try again.

I also downloaded the comedi-0.7.76 and comedilib-0.8.1, there is no problem to install them on 2.6.16-rt10, so at this point, we may try the comedi with NI PXI.

Huaqing Zhan

[Shawn B.]

mdsaero wrote:

You are right. I checked the kernel source code that in the rtmutex.c, it uses EXPORT_SYMBOL_GPL() macro instead of EXPORT_SYMBOL() macro. The rt10 patch modified the rtmutex.c from the original Vanilla kernel source. Can I replace all the EXPORT_SYMBOL_GPL() macro with the EXPORT_SYMBOL() in the rtmutex.c and then rebuild the kernel and try again.

EXPORT_SYMBOL_GPL() means that only GPL licensed kernel modules have access to those functions.  NI-KAL is not a GPL licensed kernel module so it does not have access to those functions.  There are certainly ways to work around the issue technically, but they do go against the authors original intent and the spirit of the license.

mdsaero wrote:

I also downloaded the comedi-0.7.76 and comedilib-0.8.1, there is no problem to install them on 2.6.16-rt10, so at this point, we may try the comedi with NI PXI.

As I mentioned earlier even if you get NI-DAQ successfully installed there is a good chance that it will not function correctly with the RT kernel since this is something we do not support have not tested officially.  I do think that if you need RT support that the comedi drivers are probably a better way to go.  I know that they have supported several RT Linux variants in the past so there is a better chance that they will work with your RT kernel.  However, you should also keep in mind that the comedi drivers are supported by the community and may not support all of the features or hardware you need.

Shawn Bohrer

[mdsaero]

Thank you very much.

Your help is much appreciated.

Huaqing Zhan