#50 Freezing of GPIB adapter after interrupting ibrd() call.

[Lampus]

Hello. I have Keithely KUSB-488A and using it with ni_usb_gpib driver.
linux-gpib svn revision: 1585
All works fine, until I don't send SIGINT signal (Ctrl+C) to my application during ibrd() call. After that I can't do anything with GPIB devices. "Active" LED on adapter lights permanently and all actions with board or devices fails due to timeout.
Ibsta before interrupt: ibsta = 0x130 < CMPL CIC ATN >
Ibsta after interrupt (for all calls): ibsta = 0x8164 < ERR CMPL REM CIC LACS >; iberr= 0

Part of dmesg:
[268988.729902] gpib: error while becoming active controller
[268989.733203] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[268989.733212] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[268998.733262] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[268998.733271] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[268999.736571] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[268999.736578] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[269114.919840] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[269114.919849] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[269115.923149] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[269115.923158] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[269116.926587] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[269116.926596] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_go_to_standby: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8
[269116.926599] gpib: error while going to standby
[269117.929899] ni_usb_nonblocking_send_bulk_msg: killed urb due to timeout
[269117.929907] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_line_status: ni_usb_send_bulk_msg returned -110, bytes_written=0, i=8

[Lampus]

I don't paste most interesting line of dmesg:
[274123.795443] /home/lampus/Projects/PKGBUILDs/linux-gpib-svn/src/linux-gpib/drivers/gpib/ni_usb/ni_usb_gpib.c: ni_usb_nonblocking_receive_bulk_msg: interrupted
If I properly understand, seems that problems begins because of incorrect interrupt signal handling in LKM ni_usb_gpib.

[DaveP]

This is a recurring issue for which a tested workaround is given below.

When a program receives a signal while it is in a call to a linux-gpib driver it can happen that the application hangs. This is because for historic reasons the linux-gpib driver framework does not properly handle the return of -ERESTARTSYS from its device drivers. Unfortunately to fix this systematically in the package is a lot of work. The symptoms of a hang, due to signals, are that the program receiving the signal hangs, blocking other programs from accessing the device and in the console log you can find messages such
as:

agilent_82350b: write wait interrupted.

or

.../gpib/ni_usb/ni_usb_gpib.c: ni_usb_nonblocking_receive_bulk_msg: interrupted

Note: Not all drivers returning -ERESTARTSYS generate a console message in every case. If you suspect you are having hangs due to signals you can use strace(1) on your program to check what is happening leading up to the hang.

A simple workaround is to block all signals before calls to ibrd() and ibwrt() and unblock them afterwards. For example here is a snippet for ibrd():

// Set timeout to prevent signals from being blocked for too long
err = ibtmo(myDevice,T1s); 
...
myBlockSignals();
err  = ibrd(myDevice,ibuf,max_rio_len);
myUnblockSignals();
... 

Below are sample routines for blocking and unblocking signals that should work in all single threaded programs. For multi-threaded programs using POSIX threads use pthread_sigmask(3) instead of sigprocmask(3). The man page gives a useful example.

#include <signal.h>
#include <errno.h>
#include <unistd.h>

static sigset_t mySigMask;
static int mySigBlock = 0;

void myBlockSignals() {
  sigset_t blockMe;
  int retval;

//  check against re-entry
  if (mySigBlock) error(1,0,"myBlockSignals: call count nonzero");

  sigfillset(&blockMe);  // Block all signals
  retval = sigprocmask(SIG_BLOCK,&blockMe,&mySigMask);
  if (retval) error(1,errno,"myBlockSignals: Can't block signals");
  mySigBlock++;
}

void myUnblockSignals() {
  int retval;

// check that we have had a call to myBlockSignals
  if (!mySigBlock) error(1,0,"myUnblockSignals: call count zero.");

  retval = sigprocmask(SIG_SETMASK,&mySigMask,NULL); // restore old mask
  if (retval)  error(1,errno,"myUnblockSignals: Can't unblock signals");
  mySigBlock--;
}

[Frank Mori Hess]

This should be fixed in svn now. A change was required to the library-kernel interface, so both the library and kernel modules will have to be upgraded.

[Andreas Huettel]

I can confirm the fix, tested with a NI USB GPIB adapter. Perl scripts can be cancelled with CTRL-C and then started again, no visible problems anymore. Thanks!!!