Ni-VISA 5.0.0: nipal load fails in 2.6.29.6 and 2.6.33.4 kernels

[Bryan]

From the discussion I was not surprised to have problems with the 2.6.33.4 kernel but I expected nipal to build and load correctly in the 2.6.29.6 kernel.

Configuration:  Slackware 13.1 [yes, I know it isn't supported but it has worked successfully since Slackware 10.x].

Installing: NI-VISA-5.0.0 (downloaded from ni.com 4 August 2010)

Modifications:  I had to add several soft links to the 2.6.33.4 source files to get the modules to compile.  I did this rather than edit the install scripts - it's easier.

   1.  Added a soft link for kernel_source_root/include/asm which pointed to kernel_source_root/include/generated

   2.  Added a soft link for kernel_source_root/include/linux/autoconf.h which pointed to kernel_source_root/include/generated/autoconf.h

   3.  Added a soft link for kernel_source_root/include/linux/utsrelease.h which pointed to kernel_source_root/include/generated/utsrelease.h

No changes were necessary to build on the 2.6.29.6 kernel.

Everything appeared to install correctly.  The problem came when I ran the nipal startup script (/etc/init.d/nipal).  And the problem appears to be essentially identical for both 2.6.29.6 and 2.6.33.4 kernels.  When it executes the line

    $nipalDir/bin/readInfFiles `find $nipalEtc/inf -iname \*.inf | sort` >/dev/null 2>&1

it generates a kernel oops and the process hangs.  Often I can use another window to look at what processes are running and the following three lines appear relevant:

  1755 pts/2    S+     0:00 /bin/sh ./nipal start
  1867 pts/2    S+     0:00 /bin/sh /usr/local/natinst/nipal/bin/readInfFiles /etc/natinst/nipal/inf
  1878 pts/2    D+     0:00 cat - /etc/natinst/nipal/inf/nidaqmx_NISCXI9x.inf

(there is more to each line - this is just what showed up on the screen).  The last process (1878 in this example) can not be killed.  The only way to get rid of it is to reboot the system.  I have tried this several times on both kernels and it always sticks on the same cat command.

The text generated by the kernel oops is:

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: Process cat (pid: 1875, ti=f27a2000 task=f25de050
     task.ti=f27a2000)

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: Call Trace:

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: CR2: 00000000f73fe000

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: Stack:

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: Code: a4 00 00 00 00 8b 5d 88 89 5d b4 c7 45 b8 00 00
     00 00 8b 43 08 85 c0 89 5d c4 89 45 c8 74 27 8b 75 b4 8b 4d b8 8b 56
     0c 8b 45 94 <39> 04 8a 74 2e 8d 51 01 8b 5d 88 89 55 b8 8b 43 08 39 c2
     89 5d

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: last sysfs file:
     /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: EIP: [<fa93dbb8>] nipalk-unversioned0002875+0x294/0x4a8
     [nipalk] SS:ESP 0068:f27a3e64

     Message from syslogd@newion at Thu Aug 12 12:52:08 2010 ...
     newion kernel: Oops: 0000 [#1] SMP

The dmesg command adds the messages:

     BUG: unable to handle kernel paging request at f73fe000
     IP: [<fa93dbb8>] nipalk-unversioned0002875+0x294/0x4a8 [nipalk]
     *pde = 00007067 *pte = 00000000
     Oops: 0000 [#1] SMP
     last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading
     Modules linked in: nipalk(P) nikal(P) radeon ttm drm_kms_helper drm i2c_algo_bit snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 lp fuse usbhid hid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer ppdev uhci_hcd snd soundcore parport_pc snd_page_alloc intel_agp tg3 led_class rtc_cmos processor ehci_hcd thermal button rtc_core agpgart parport libphy thermal_sys psmouse i2c_i801 rtc_lib i2c_core dcdbas hwmon evdev sg serio_raw ext4 mbcache jbd2

     Pid: 1875, comm: cat Tainted: P           2.6.33.4-smp #1 0HH807/OptiPlex GX620              
     EIP: 0060:[<fa93dbb8>] EFLAGS: 00010206 CPU: 0
     EIP is at nipalk-unversioned0002875+0x294/0x4a8 [nipalk]
     EAX: f269c9e8 EBX: fa985880 ECX: 013191bc EDX: f2799910
     ESI: fa985880 EDI: f269a738 EBP: f27a3ee4 ESP: f27a3e64
     DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
     Process cat (pid: 1875, ti=f27a2000 task=f25de050 task.ti=f27a2000)
     Stack:
      f68f1dc8 fa97d7d8 fa985880 00000000 f27a3ea4 f269c9e8 00000000 00000000
     <0> 00000000 f269a738 fa961cf8 f27a3ebc 00000000 fa985880 013191bc 00000000
     <0> f27a3ee8 fa985880 00000001 fa93554d f27a3ebc fa985880 0000295a f27a3ee0

     Call Trace:
      [<fa961cf8>] ? _ZNV14tSyncAtomicU32mmEi+0x14/0x30 [nipalk]
      [<fa93554d>] ? nipalk-unversioned0002590+0x55/0x7c [nipalk]
      [<fa91e96d>] ? nipalk-unversioned0002405+0x29/0x48 [nipalk]
      [<fa91de38>] ? nipalk-unversioned0002396+0x1b8/0x1ec [nipalk]
      [<c10c8a7a>] ? handle_mm_fault+0x11a/0x830
      [<f7c3cbd4>] ? nNIKAL100_release+0x24/0x50 [nikal]
      [<c10e12b4>] ? __fput+0xe4/0x1e0
      [<c10e13cd>] ? fput+0x1d/0x30
      [<c10ddc1c>] ? filp_close+0x4c/0x80
      [<c10ddcac>] ? sys_close+0x5c/0xa0
      [<c13f7c34>] ? syscall_call+0x7/0xb
     Code: a4 00 00 00 00 8b 5d 88 89 5d b4 c7 45 b8 00 00 00 00 8b 43 08 85 c0 89 5d c4 89 45 c8 74 27 8b 75 b4 8b 4d b8 8b 56 0c 8b 45 94 <39> 04 8a 74 2e 8d 51 01 8b 5d 88 89 55 b8 8b 43 08 39 c2 89 5d
     EIP: [<fa93dbb8>] nipalk-unversioned0002875+0x294/0x4a8 [nipalk] SS:ESP 0068:f27a3e64
     CR2: 00000000f73fe000

I haven't been able to find anything in this dump that tells me what to try to fix to make this work properly.  Any hints would be appreciated.

Bryan Peterson

bryan_peterson@byu.edu

[dcxemc]

It's not just Slackware.  I'm having the exact same thing happen in Debian 5.0.5 with 2.6.26.  About the only difference is the actual addresses it lists and the modules linked in.

Editing to add: This worked in Scientific Linux 5.5.  The kernel was something like 2.6.18.

[Josh Cartwright]

I'm sorry you both have run into this problem, but we've been working to find out what went wrong.  At this point we identified the source of the problem, and are shooting to have a fix out there by the end of next week (Friday 8/27).  Stay tuned, as I'll be posting here where to find the fix when its posted.

[Josh Cartwright]

We ran into another problem with our testing, and won't be able to put an official fix up until next week.

There is, however, a workaround, that should get you going:

# rm /usr/local/natinst/nipal/etc/inf/nidaqmx_NIES9x.inf

You'll need to run the command as root.  Removing this symbolic link will allow the service to continue its startup without crashing.  Sorry again for the inconvenience.

[dcxemc]

Ok, I got thru the startup, what will or won't work?   I can't control the relays on an SCXI-1166.  Is that to be expected?

[JoeFriedchicken]

What steps have you taken to try to control the SCXI-1166? Did you configure the SCXI chassis and modules?

Using nidaqmxconfig for NI-DAQmx 8 for Linux

http://zone.ni.com/devzone/cda/tut/p/id/4620

[dcxemc]

That was already done.  All I *should* have to do is compile and run a test program previously written and tested.  Do I need to rerun nidaqmxconfig if the OS is changed or is that stored in the PXI chassis?  I was under the impression it was stored in the chassis.

[dcxemc]

Followup.  I guess it doesn't store it in the chassis.  I did an export and none of the SCXI stuff was in there so I reconfiged and that part is working now.  Thanks Joe!

[JoeFriedchicken]

Hi Vince,

The configuration is stored on the local filesystem, so depending on how you changed the OS, it's possible that the configuration was overwritten or deleted. What does

nidaqmxconfig --export currentConfig.txt

tell you about your system?

[Justin_E]

Hey everyone, we just released a fix for this issue. Info can be found in KB 5D2ERAUS