Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 08 Aug 2007 17:03:54 +0200

Ouch!
Thanks for your reply. I was hoping for the relieving news that I was
only being stupid ... now look at this.

Your impression of statistical misfunction (especially more errors on
supposedly faster systems) leads to the .... huagh! .... thought that
this might be connected to timing issues or race conditions between the
CA server and the Access Security system.
Jeff - do you recall a Channel Access change between 3.14.8.2 and 3.14.9
that you can relate?
Regards,
Ralph
ps. There were also some parser cleanup things done to the asLib for
3.14.9, but these don't look dangerous, either. I will try to just use
the as subdirectory from 3.14.8.2 to rule out that possibility.

Steven Hartman wrote:

On Wed, 8 Aug 2007, Ralph Lange wrote:

Does anyone have similar experiences?

Yes! I have just been investigating the same problem, though my symptoms
are slightly different then yours (and even more strange).
The problem seems to be restricted to 3.14.9 IOCs (do not see it with
3.14.8.2 or 3.13.10). I have observed it with both VxWorks (5.5.1 on
MVME5110-2261 with WRS compilers) and Linux (2.6 kernel, x86) IOCs.
The stranger part is the client access side (using Linux and Solaris
clients).  Some 3.14.9 clients always work as expected (medm, camonitor,
alh, adt, burt).  Other 3.14.9 clients (same host, same user) sometimes
work but usually get a no read access error (caget, StripTool, probe). I
am not seeing any unexpected no write access errors. Caput often shows a
no read access error (from the caget() function) but then a successful
write. All 3.13.10 (Solaris) clients appear to work as expected. I have
not seen any read access errors over channel access from IOC to IOC.
Some additional observations: Linux 3.14.9 caget seems to have a much
higher unexpected no-read access error rate (>90%) then Solaris 3.14.9
caget (<40%).  Passing 2 PVs to caget (one PV on 3.14.9 IOC one on 3.13.10
IOC) always results in a successful read of both PVs.
Not enabling access security on the IOC makes the problem go away. But the
problem appears with an access_security.acf file which is used
successfully for IOCs at other EPICS versions. Even a minimal
access_security.acf file (default read and write access for anyone) shows
this problem. I have not seen any problem of access security not denying
when it should. Access security dump routines are consistent with the
input file and consistent with IOCs at < 3.13.10. I am not using any calc
expressions in this access_security.acf file.
There were changes in the calc expression parser between 3.14.8.2 and

3.14.9 which impacted asLib,

(http://www.aps.anl.gov/epics/base/R3-14/9-docs/RELEASE_NOTES.html), but

given the strange client side behavior, I suspect that this is not where

the problem lies.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System