NI 4462 and DAQmx under Mandriva 2009.1, kernel 2.6.29 (HOWTO)

[RichardNeiill]

NI's official Linux support is only for post-end-of-lifed distributions at this point. The rather ugly NIKAL binary-blob is also limited to 32-bit systems, restricted to 4GB of RAM, and only officially works with kernels that are so old that the kernel/distro doesn't work on a modern motherboard (example: if I want to use DAQmx 8.01, then I am officially limited to Mandriva 2008, which is end-of-lifed, doesn't get security updates, and doesn't support my motherboard's ethernet device!). However, we were able to force DAQmx 8.01 to install on Mandriva 2009.1 (32-bit), and this log may be of use...

Note - this isn't a perfect howto, it's a copy of my lab notebook - so you may not need all the steps. However, it DOES actually work. The most critical bits are the "pte_offset_kernel=1" and "init_mm_hack". Be cautious with the latter...you could crash your system.

1. Get the latest version of DAQmx, and attemt to install:

     sudo ./INSTALL

2. It complains:

******************************** ERROR ****************************************
* Kernel source in /lib/modules/2.6.29.6-desktop586-3mnb/source does not appear to be
* configured for the 2.6.29.6-desktop586-3mnb kernel.
* Configuration of kernel source is required to continue installation.        *
* Refer to the README file for the product you are installing for information *
* about configuring your kernel source.                    
******************************** ERROR ****************************************

However, I do have the correct kernel and matching kernel-source package installed, (see uname -r).
This is because Mandriva does something clever to build multiple kernels from one source tree.

3. Solution.

i.  #Get the ".config" file from the running kernel, and put it where it should be.
    cd /lib/modules/2.6.29.6-desktop586-3mnb/build/        #use `uname -r`
    cat /proc/config.gz | gunzip  > .config

ii. #Rebuild source:
    make oldconfig
    make modules_prepare  

iii. #Now we get the slightly different error. Note "does not appear to BE FOR the" rather than "be CONFIGURED for the" as above.

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

This is of course incorrect. However, even running "make" and waiting overnight doesn't fix it.

The reason is that "make oldconfig" changes the 2nd line in the .config and the UTS_RELEASE in utsrelease.h
from "2.6.29.6-3mnb" to "2.6.29.6-3mnbcustom", which is completely WRONG.

iv. So try this.

    cd /lib/modules/2.6.29.6-desktop586-3mnb/build/
    cat /proc/config.gz | gunzip  > .config
    make oldconfig
    mv .config.old .config
    make modules_prepare

    #Then edit:   include/linux/utsrelease.h
    #and change:  #define UTS_RELEASE "2.6.29.6-3mnbcustom"
    #back to:  #define UTS_RELEASE "2.6.29.6-3mnb"

    sed -i 's/custom"/"/' include/linux/utsrelease.h

    #That's better, but it still isn't right. The UTS_RELEASE is "2.6.29.6-3mnb"
    #but the kernel version is "2.6.29.6-desktop586-3mnb".

    Try forcing it:
    echo '#define UTS_RELEASE "'`uname -r`'"' > include/linux/utsrelease.h

This works: the installer no longer sulks.

The installer proceeds, but dies during the kernel compile stage with:

/bin/cp nikal.c objects/nikal.c
/bin/cp nikal.h objects/nikal.h
make -C /lib/modules/2.6.29.6-desktop586-3mnb/source SUBDIRS=/usr/local/natinst/nikal/src/objects modules
make[1]: Entering directory `/usr/src/linux-2.6.29.6-3mnb'

  WARNING: Symbol version dump /usr/src/linux-2.6.29.6-3mnb/Module.symvers
           is missing; modules will have no dependencies and modversions.

  CC   /usr/local/natinst/nikal/src/objects/nikal.o
/usr/local/natinst/nikal/src/objects/nikal.c: In function ‘nNIKAL100_getKernelPageTableEntry’:
/usr/local/natinst/nikal/src/objects/nikal.c:1795: error: implicit declaration of function ‘pte_offset’
/usr/local/natinst/nikal/src/objects/nikal.c:1795: warning: assignment makes pointer from integer without a cast
/usr/local/natinst/nikal/src/objects/nikal.c: In function ‘nNIKAL100_mapUserPageTableEntry’:
/usr/local/natinst/nikal/src/objects/nikal.c:1808: warning: return makes pointer from integer without a cast
/usr/local/natinst/nikal/src/objects/nikal.c: In function ‘nNIKAL100_getPhysicalAddress’:
/usr/local/natinst/nikal/src/objects/nikal.c:1996: warning: assignment makes pointer from integer without a cast
make[2]: *** [/usr/local/natinst/nikal/src/objects/nikal.o] Error 1
make[1]: *** [_module_/usr/local/natinst/nikal/src/objects] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.29.6-3mnb'
make: *** [objects/nikal.ko] Error 2

ERROR: make of nikal kernel module failed, not installing kernel module.
   updateNIDrivers should be called again after fixing the problem.
   Logging failure...
   Include the file /tmp/niSystemReport.out.gz when contacting
   National Instruments for support.

Note: out-of-tree modules are no longer built with SUBDIRS (and that was deprecated ages ago). So change:
make -C /lib/modules/2.6.29.6-desktop586-3mnb/source SUBDIRS=/usr/local/natinst/nikal/src/objects modules
to
make -C /lib/modules/2.6.29.6-desktop586-3mnb/source M=/usr/local/natinst/nikal/src/objects modules

This doesn't work either.

Also, the pte_offset function was moved out of asm/ into the main kernel tree. So.

(a)Having done the above, and run the installer as far as possible.

(b)Edit the configure script:
    cd /usr/local/natinst/nikal/src
    cp configure configure.NI-orig
    chmod +w configure
    Edit the file "configure":
   
    #RJN/MCB - this is grepping the wrong place
    #pte_offset_kernel=`$GREP -d skip pte_offset_kernel $headersDir/include/asm/* | $GREP -wc pte_offset_kernel`
    #force it
     pte_offset_kernel=1
    #END

   ./configure

(c)At this point, one might want to run ./configure && make, but it won't work.
The nikal.c file uses init_mm; however this symbol was unexported after 2.6.28 (we are using 2.6.29) because
no out-of-tree code should be using it. We have a very very ugly workaround, that functions on this kernel on this system.
At line 96 of nikal.c  (just before "#ifndef nNIKAL100_kPutPageTestzero"), insert the following:

    /*
     * Extreme hack.  init_mm was unexported in 2.6.29, on the basis that
     * no out-of-tree code should be using it.  Extract the value applicable to the currently running kernel using:
     *
     *   grep init_mm /proc/kallsyms
     *
     */
    struct mm_struct *init_mm_hack = ( struct mm_struct * ) 0xc04e41a0;
    #define init_mm (*init_mm_hack)
    /* END hack */

Note that the value 0xc04e41a0 is derived from `grep init_mm /proc/kallsyms` with '0x' prepended.

WARNING...this value is ONLY good for THIS kernel. If you build this module on the wrong kernel, without changing this value,
something VERY VERY BAD WILL HAPPEN.!!!  We are essentially hard-coding an address into the driver....

(d) make
   ./install.sh     #same as make install

4.  Check all of the following symlinks are present in /usr/local/natinst/nikal/etc/clientkdb/nicore :

nidimk-unversioned.o -> /usr/local/natinst/.nicore/src/objects/nidimk-unversioned.o
nimdbgk-unversioned.o -> /usr/local/natinst/.nicore/src/objects/nimdbgk-unversioned.o
nimru2k-unversioned.o -> /usr/local/natinst/.nicore/src/objects/nimru2k-unversioned.o
nimxdfk-unversioned.o -> /usr/local/natinst/.nicore/src/objects/nimxdfk-unversioned.o
niorbk-unversioned.o -> /usr/local/natinst/.nicore/src/objects/niorbk-unversioned.o

Run:
    updateNIdrivers

This will build all the modules and ask for a reboot. We don't need to reboot here.

5. Finally, we want to run: /etc/init.d/nipal start
However, it won't work because, although the module versions are correct, some of the individual symbol versions't right.

    # modprobe nipalk
    FATAL: Error inserting nipalk (/lib/modules/2.6.29.6-desktop586-3mnb/kernel/natinst/nipal/nipalk.ko): Unknown symbol in module, or unknown parameter
    # modprobe --force-modversion nipalk
    This works.

So, we could correct /etc/init.d/nipal:
    sed -i 's/modprobe/modprobe --force-modversion/g' /etc/init.d/nipal
   
But there is a better way, which fixes all the similar initscripts and every instance of module loading:

  echo "#The National Instruments ni-modules that we compiled need persuaded to load without the modversion checks." > /etc/modprobe.d/ni-modules
  for module in $(find  /lib/modules/`uname -r`/kernel/natinst/ -name '*.ko') ; do
    echo "install $(basename $module .ko) /sbin/modprobe --ignore-install --force-modversion $(basename $module .ko)" >> /etc/modprobe.d/ni-modules
  done

Finally, stop and start the nipal service:
 
    /etc/init.d/nipal restart

    lsmod | grep ni

        nipxirmk
        nidimk
        nimsdrk
        nidmxfk
        nimxdfk
        nimstsk
        nimdbgk
        niorbk
        nipalk
        nikal

6. nilsdev:
    #shows nothing, returns immediately.

Reboot (as it wanted originally)

  nilsdev now prints a single blank line...

7. In general, the reboots are always required at some point.

lspci -v  now shows that the device is associated with the driver nidaqmx_NIDSA9x

nilsdev still showing nothing.

modified nikal.c (by adding some printk) then updateNIdrivers and reboot; can see debug info in dmesg.

8. Now read ConfigurationGuide.html - explains nilsdev and nidaqmxconfig

nilsdev (--verbose) prints a blank line only.

nidaqmxconfig --export temp.txt shows:
    [DAQmx]
    MajorVersion = 8
    MinorVersion = 0

9. Why isn't nilsdev showing anything?

nikal.c has a debugging feature (line 129), "ifdef nNIKAL100_kDebuggingIsActive". This can be
turned on by ./configure, but since we need to run updateNIdrivers, simply modify the line to force it on:
   #if 1 /* ifdef nNIKAL100_kDebuggingIsActive  (HACK; turn on debugging)*/

re-run updateNIdrivers and reboot.

#And fix the modprobe.d/ni-modules, as above

10. At LONG LAST, this finally works.

Running nilsdev:
  NI PCI-4462: "Dev1"

Running nidaqmxconfig:
# nidaqmxconfig --export /tmp/nidaqmxconfig ; cat /tmp/nidaqmxconfig
    Operation successful.
    [DAQmx]
    MajorVersion = 8
    MinorVersion = 0

    [DAQmxDevice Dev1]
    ProductType = PCI-4462
    DevSerialNum = 0x152BD11
    BusType = PCI
    PCI.BusNum = 0x3
    PCI.DevNum = 0x8

11. Now, we need to configure this device, and make this device do something...
    Suggested: DAQmxTestPanels, but this errors with:
        Can't load LabVIEW runtime library /usr/local/lib/liblvrt.so.8.0
        libOSMesa.so.4: cannot open shared object file: No such file or directory

   The liblvrt.so.8.0 is there; the Mesa library is missing (and according to urpmf, nothing provides it).
   libOSMesa.so.4 seems to have been part of XFree86.

   According to this post: http://forums.ni.com/t5/LabVIEW/The-libOSMesa-nightmare/m-p/407634 , there is source
   at ftp://ftp.ni.com/support/misc/thirdparty/mesa-src
   So, I downloaded this into mesa/ and unzipped
    cd mesa; make -j4 lv-linux
    This is problematic, and doesn't build.

   It seems to be that libOSMesa is now gone. But /usr/include/GL/osmesa.h defines OSMESA...
    /usr/include/GL/osmesa.h is in the package libmesagl1-devel, which also provides /usr/lib/libGL.so
   Try:
     ln -s /usr/lib/libGL.so /usr/lib/libOSMesa.so.4
   
   Now, DAQmxTestPanels complains:
    /usr/local/lib/liblvrt.so.8.0: undefined symbol: OSMesaGetCurrentContext
   which is odd, because OSMesaGetCurrentContext is defined in /usr/include/GL/osmesa.h
   Indeed,  grep -r OSMesaGetCurrentContext /usr/lib  shows nothing at all!

   BUT, I do have a copy on the Mandriva 2006 system. So
    scp www:/usr/X11R6/lib/libOSMesa.so.4.0 /usr/lib/libOSMesa.so.4        #ugh!

   Close, but no good:
    # DAQmxTestPanels
    Can't load LabVIEW runtime library /usr/local/lib/liblvrt.so.8.0
    /usr/lib/libOSMesa.so.4: undefined symbol: driDispatchRemapTable

   Try a small C-program with /usr/include/GL/osmesa.h, osmesa_is_where.c
    gcc -o osmesa_is_where.o -c osmesa_is_where.c -W -Wall -Wextra
    cc -o osmesa_is_where osmesa_is_where.o  -lGL -lGLw -lglut -lGLU
        osmesa_is_where.o: In function `main':
        osmesa_is_where.c:(.text+0x1e): undefined reference to `OSMesaGetCurrentContext'
        collect2: ld returned 1 exit status

   Back to google:
    http://forums.ni.com/t5/LabVIEW/LabVIEW-8-0-1-RTE-Red-Hat-Linux/td-p/805952/page/2     at  11-18-2008  03:30 PM      
  
       Save:  http://forums.ni.com/ni/attachments/ni/170/369499/1/libLVMesa.tar.gz   in labview-download
    (this is 1 MB when unzipped)   
   
    mkdir /usr/local/lib/linux
    cp libLVMesa.so.4 /usr/local/lib/linux
    cd /usr/local/lib/linux ; ln -s libLVMesa.so.4 libOSMesa.so.4
    #The post also refers to chcon, but not required on Mdv.

    Now run DAQmxTextPanels

    ...Something happens 🙂

Actually programming it:

See:   /usr/local/natinst/nidaqmx/docs/cdaqmx.chm/_main.html

And then, for example:
  /usr/local/natinst/nidaqmx/examples/ansi_c/AnalogIn/MeasureVoltage/Acq-IntClk

#Note that this will build and run correctly, but doesn't actually print the captured data...a helpful addition to Acq-IntClk.c is:

for (i=0;i<1000;i++){
       printf("Data value %d is %f\n",i,data);
}

Credit to Michael Brown of fensystems.co.uk for much of this.

[RichardNeiill]

P.S. to underline the point about init_nm_hack, you may wish to look at the following:

   http://thereifixedit.files.wordpress.com/2010/01/129072652699471246.jpg

Yes, it works. But if you recompile the module for a new kernel, without fixing the value of 0xc04e41a0.....

[JoeFriedchicken]

You're right, NI has dropped support for Mandriva and has instead continued support for openSUSE (the latest version supported is 11.2), RHEL (the latest is 5), and Scientific Linux (the latest is 5). Indeed, that last version of Mandriva supported by NI drivers is Mandriva 2009 [1]

The "ugly" NI-KAL binary blob is the only piece that needs to be updated to match kernel versions, as you've labored to do (though I reckon it look longer to tweak NI-KAL than it would have to switch Linux distros ;-). However, the DAQmx stack sits on top of NI-KAL, so all you need to do to support a newer Linux distribution than what DAQmx 8.0.1 does is install the version of NI-KAL that supports your kernel [2] and then install whichever NI device driver you need. RedHat and DAQmx have a storied relationship [3], but that distro and driver combination is the only corner-case.

At any rate, thanks for reporting your steps for hacking DAQmx 8.0.1 into Mandriva 2009.1. Future readers, you may want to try installing a newer/matched version of NI-KAL before installing NI-DAQmx (or any other NI device driver). Failing that, hack away at NI-KAL and share your frustration here. We're listening!

Joe

[1] NI-KAL 1.9 readme
http://ftp.ni.com/support/softlib/kal/1.9/readme.txt

[2] NI-KAL driver search
http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/ps/10/sn/ca tnav:du,ssnav:sup/q...

[3] 8k kernel stack prevents overflow
http://forums.ni.com/t5/Multifunction-DAQ/DAQmxBase-Acquiring-at-high-frequency/ m-p/781433#M43258