devSup driver development differences between base 3.14 and 3.15

[Abdalla Ahmad via Tech-talk <tech-talk@aps.anl.gov>]

Hi

 

When we had EPICS base 3.14.12.3 and .6 we had a driver developed using EPICS devSup model and it was working fine. Now with EPICS base 3.15.6 the driver is running fine for some period of time until, for unknown reason, the server gets 100% CPU usage. After restarting the server I noticed that (through htop) the IOC’s memory usage is actually increasing although not in a high rate. We noticed the same behavior with another driver we developed. The first one was using a standard socket to communicate while the second one is using SNMP v1.

 

The devSup structure is defined in the device support as:

 

struct devsup {

                long number;

                DEVSUPFUN report;

                DEVSUPFUN init;

                DEVSUPFUN init_record;

                DEVSUPFUN get_ioint_info;

                DEVSUPFUN io;

                DEVSUPFUN misc;

} aiDevice = {

                6,

                NULL,

                Init,

                initRecord,

                NULL

                ioRecord,

                NULL

};

 

And drvet structure is defined in the driver support as:

static drvet drvDevice = {

                2,

                NULL,

                Init

};

 

Here is how everything works in the driver:

1.       The drvet init function initializes communication to the configured devices and fills up array of structures each for a single device.

2.       The devSup init record parses the INP field, gets the device name and uses it to get the device from the previous array storing it in the record’s DPVT.

3.       The devSup io record function reads the DPVT and creates a POSIX thread.

4.       This thread is detached and reads the parsed INP field and calls the corresponding function from the driver support.

5.       All driver support functions communicate with the corresponding device, fetch the value and stores it in the record’s VAL pointer.

6.       After that, dbScanLock is called followed by a call to the record’s RECSUPFUN process function pointer, then dbScanUnlock is called.

 

Right now I am investigating the driver’s code for any possible bugs, but I am sure the problem is that we are doing something wrong which was done right with base 3.14.12.3. Where could be the problem? Let me know if further info Is needed.

 

We are aware of the benefits of asyn-based drivers but we did not have time to do something from scratch. It would be very helpful if there are good material on developing asyn-based drivers.

 

Best Regards,

 

Abdalla Ahmad

Control Engineer

SESAME

Allan, Jordan.

Tel: (+962-5) 3511348 , ext. 265

Fax: (+962-5) 3511423

Mob: (+962-7)88183296

www.sesame.org.jo