lsdaq sometimes hangs on Scientific Linux 6.1

[grdetil]

I've upgraded to nidaqmxbase 3.4.5 on Scientific Linux 5.7 and I find it's a nice improvement on 3.4.0.  The README.txt file for it says it supports Red Hat Enterprise Linux WS 5 and 6, so I thought I'd give it a try on Scientific Linux 6.1.  It does work there, but with one rather annoying problem.  I find that the lsdaq program, which my software requires for discovering NI devices under DAQmx Base (no DAQmxGetSysDevNames and DAQmxGetDevProductType equivalent available unfortunately), will occasionally hang on this system.  It happens especially frequently when there's no USB device connected, or the first time after it is connected.  (I'm using an NI USB-6210 device.)  This is with kernel version 2.6.32-131.12.1.el6.i686.  Is there a fix or workaround for this?  Until there is, I don't think we'll be able to upgrade from SL 5.7 to SL 6.x.

[Dave-C]

Hi grdetil,

I am glad to hear that the newer version performs better! Unfortunately, as you've read, SL 6.X isn't a supported OS for this driver, so there's no officially endorsed work arounds.  That said, another developer may be able to help out.  I've also got a couple of other questions that I'd like to clarify about this issue.

You've mentioned that the program hangs the first time after the USB is connected.  Is this the case everytime, or just a typical occurrence?  I'm also curious, when the program hangs, is there an error message, or does it simply become unresponsive and stuck?

Thanks, 

-Dave C

[grdetil]

Though SL 6 isn't officially supported, I have to wonder, given that it's built from the same source code as RHEL 6 (which is officially supported), doesn't the same problem occur with lsdaq on RHEL 6?

As for the nature and frequency of the hanging problem I've noticed, it's not every time, and it's hard to pin down a pattern.  There are no error messages, either on screen in in /var/log/messages.  The /etc/natinst/nidaqmxbase/bin/daqmxbase_listdevices executable just starts up and quietly sits there doing nothing, and doesn't end.  This seems to happen (very roughly) 10-20 % of the time I run it when the USB-6210 is disconnected.  It seems to happen a little more frequently after a reboot than after the system has been running for a while, i.e. after several successful runs of lsdaq, it seems to fail less often afterwards, but the first few seem more likely to hang.  Once lsdaq is hung, reconnecting the USB-6210 never seems to wake up the hung process - it stays stuck until I kill it (Ctrl-C or kill command both work).

The frustrating thing for me is my application uses a client/server model, with the server interacting with the DAQ device.  This hanging problem causes the whole server to hang, and it doesn't get unstuck by connecting the device, so I end up having to look for and kill either the daqmxbase_listdevices process or the server process.  So, if I don't make sure the USB-6210 is connected before starting up the system, there's a high likelyhood that the capture application won't work even after the device is connected.  And in a few cases it hung even when restarting with the device connected (though not frequently).  Not something I feel is ready to put in the users' hands.  I'm sticking with SL 5.7 for now, but I'm hoping this issue will be resolved by the time we feel the need to upgrade.

Thanks,

Gilles

[grdetil]

I came up with a partial workaround which helps, but doesn't completely solve the problem.  What I did was rename the daqmxbase_listdevices executable in /etc/natinst/nidaqmxbase/bin to daqmxbase_listdevices.real, and replaced the original daqmxbase_listdevices command with this wrapper script:

#!/bin/sh

if (lspci; lsusb) | grep -q National.Instruments
then
        /etc/natinst/nidaqmxbase/bin/daqmxbase_listdevices.real
fi

This prevents daqmxbase_listdevices (the real one) from running if there are no PCI or USB NI devices on the system, preventing most of the hangs.  There is still the problem of it sometimes hanging the first time it's run after the USB device is plugged in.