RE: ASYN Module: Workaround for bug due to improper handling of signal in linux-gpib

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Kuldeep,

 

Does the problem occur only when exiting the IOC?

 

It sounds like you already tried the workaround in the link you sent and it does not help?

 

Ø  Is there a function call in epics iocsh to decouple the Gpib drivers before exiting the shell?

 

EPICS provides the capability to provide an epicsAtExit callback function.  It appears that drvLinuxGpib.c does not do that.  You could try adding that to the driver, and then call whatever code is needed to unload or stop the Gpib drivers during IOC exit.

 

I don’t have any hardware to test with, so I am going to need to rely on you or others who use drvLinuxGpib.c to develop a fix and issue a pull request.

 

Mark

 

 

From: Kuldeep Joshi <kuldeep.joshi at gmail.com>
Sent: Wednesday, February 10, 2021 7:15 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk at aps.anl.gov
Subject: Re: ASYN Module: Workaround for bug due to improper handling of signal in linux-gpib

 

Hi Mark,

I am using the version  4.3.3 of linux-gpib. I guess the problem is still present.

Every time I restart the epics iocsh shell the problem occurs. with the dmesg listing below

It occurs randomly as well.

 

I inserted the fix as suggested around ibrd and ibwrt in drvLinuxGpib.c. The problem is still present. i have used pthread_sigmask instead of sigprocmask

Will adding a pthread_sigmask  around all calls to the functions ib...() call help??.

Is there a function call in epics iocsh to decouple the Gpib drivers before exiting the shell?

 

Regards,

Kuldeep

 

PS: I am using Raspberry PI. I am using synApps and xxx implementation. The code is modified in the synApps:asyn module, then built only the asyn module and the ioc implementation of xxx

 

dmesg listing after exiting the epics iocsh:

-512 is the return code for ERESTARTSYS error

 

[  236.769723] /home/pi/Downloads/linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/agilent_82357a/agilent_82357a.c: agilent_82357a_receive_bulk_msg: interrupted
[  236.769765] /home/pi/Downloads/linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/agilent_82357a/agilent_82357a.c: agilent_82357a_read_registers: agilent_82357a_receive_bulk_msg returned -512, bytes_read=0
[  236.769770] agilent_82357a_dump_raw_block:

[  236.769777] /home/pi/Downloads/linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/agilent_82357a/agilent_82357a.c: agilent_82357a_update_status: agilent_82357a_read_registers() returned error
[  236.769788] /home/pi/Downloads/linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/agilent_82357a/agilent_82357a.c: agilent_82357a_send_bulk_msg: interrupted
[  236.769972] /home/pi/Downloads/linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/agilent_82357a/agilent_82357a.c: agilent_82357a_read_registers: agilent_82357a_send_bulk_msg returned -512, bytes_written=0, i=3

 

 

On Wed, Feb 10, 2021 at 12:14 PM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Hi Kuldeep,


Have you been seeing this issue?  If so, how hard is it to reproduce?


I looked at the bug report link in your message.  At the end there are 2 comments:


*******************************************

Frank Mori Hess - 2015-04-04
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 - 2015-04-07
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!!!
*******************************************

So this suggests that the problem was fixed in the linux-gpib package almost 5 years ago.


If so, is it possible for you to upgrade to a more recent version?


Mark



________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Kuldeep Joshi via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, February 10, 2021 2:05 AM
To: tech-talk at aps.anl.gov
Subject: ASYN Module: Workaround for bug due to improper handling of signal in linux-gpib

Hello,

Can the workaround as suggested in this link https://sourceforge.net/p/linux-gpib/bugs/50/#85e8
be incorporated for the drvLinuxGpib.c in the ASYN module.
The workaround suggests to mask all the signals during call to ibrd() or ibwrt()

Thanks and regards,
Kuldeep

The text of the above link is reproduced as 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


"