Experimental Physics and
Industrial Control System

Ric Claus <[email protected]> · Tue, 18 Feb 1997 19:42:28 -0800

We (SLAC's PEP-II RF group) are having a problem with hanging/crashing 
IOCs and wonder if anyone has some suggestions.  We're running EPICS 
R3.13.0.beta4 with dm version 2.3.  The processor is a National 
Instruments VXIcpu-030 with 8 MB of RAM.  When everything is up and 
running normally we see about 2 MB of free memory.  Task stacks are not 
close to the edge.  There is no VXI interrupt activity, although perhaps
some are being genterated by the Allen Bradley scanner module.

Occasionally we see the Allen Bradley driver spontaneously changing the 
status of all connected links from good to bad.  Sometimes they go back 
to good a moment later, sometimes it's a long while later, sometimes not 
at all.  There is nothing an operator can do to cause this directly.  
The blue hose is not being unplugged or anything like that.  We're
using a 6008-SV1 scanner module.

When an IOC crashes or hangs, there is generally nothing to see on the
console port record.  Once, however, I saw tNetTask trying to say 
something, but it never made it out.

One possibility I wonder about is that CA clients cause the creation 
of "CA client" and "CA event" tasks that consume a lot (800 Mb) of 
memory.  Perhaps these crashes are due to one too many dm sessions
being fired up in people's offices.  Is there a way to limit the
number of CA clients?  If not, shouldn't such a thing be added?
What do these tasks do with that much memory?  When IOC resources 
run out, does CA currently stop allowing new client connections or 
does it let the IOC die?  How do other people handle this situation?  
Just add more memory?

	Thanks,
		Ric

-- 

	Ric Claus	([email protected], (415) 926-2697)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System