EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: IOC Errors when StripTool is Running
From: "Christopher A. Larrieu" <[email protected]>
To: Jeff Hill <[email protected]>
Cc: John K Munro Jr <[email protected]>, [email protected], [email protected]
Date: Wed, 16 Feb 2000 09:36:48 -0500
John,

  StripTool sets up one monitor for each signal plotted, which
is not very different from most other channel access clients.  
Is it possible to run a different program (e.g. cau) to monitor
the exact same signals?  Doing so may help determine if the
problem is specific to StripTool or if it is owing to some other 
interaction between the ca client and the IOC.  I know that the 
alarm handler and StripTool differ slightly in how they pass of
control to the CA library.

  Several questions: are the alarm handler and StripTool both 
compiled with the same version of the CA library?  (I'm not 
certain that this would matter, but you never know).  Also,
does this problem occur right upon startup, or after the
program has been running for a while?  Does it happen even
if you never muck with the controls (e.g. clearing the graph,
deleting curves and adding new ones, etc.)?  Finally, are you
using the CA or CDEV version of StripTool?

  Thanks,

Chris

Jeff Hill wrote:
> 
> >
> > "Attached are the intermittent memory errors we are getting on the ioc. I
> > would think some of your contacts in the EPICS community would be able to
> > tell us what these mean, if not what's causing them."
> >
> > 0x1fa2d4 (CA TCP): CAS: task creation for new client failed because
> > "S_memLib_NOT_ENOUGH_MEMORY"
> 
> These error messages certainly indicate that the IOC has insufficient space
> in
> memory to allow a new client to attach. This is probably because the total
> client initiated load is too high, but could also be caused by other
> problems
> such as a memory leaking program, a large database, or corruption
> of pool. It is possible that one client is creating a disproportionate load.
> To find out if this is the case type "casr <interest level>" on the IOC.
> 
> Jeff
> 
> > 0xf0cc4 (CA client): memPartAlloc: block too big - 25072 in partition
> > 0xafae8.
> > 0xf0cc4 (CA client): CAS: unable to init the event facility
> > iocA~> 0x1fa2d4 (CA TCP): memPartAlloc: block too big - 11412 in partition
> > 0xafae8.
> > 0x1fa2d4 (CA TCP): CAS: task creation for new client failed because
> > "S_memLib_NOT_ENOUGH_MEMORY"
> > iocA~> 0xf0cc4 (CA client): memPartAlloc: block too big - 25072 in
> > partition 0xafae8.
> > 0xf0cc4 (CA client): CAS: unable to init the event facility
> > 0xf0cc4 (CA client): memPartAlloc: block too big - 25072 in partition
> > 0xafae8.
> > 0xf0cc4 (CA client): CAS: unable to init the event facility
> > 0xf0cc4 (CA client): memPartAlloc: block too big - 25072 in partition
> > 0xafae8.
> > 0xf0cc4 (CA client): CAS: unable to init the event facility
> > iocA~>
> > iocA~>
> > iocA~> 0x1fa2d4 (CA TCP): memPartAlloc: block too big - 11412 in partition
> > 0xafae8.
> > 0x1fa2d4 (CA TCP): CAS: task creation for new client failed because
> > "S_memLib_NOT_ENOUGH_MEMORY"
> > 0xf2bd0 (CA client): memPartAlloc: block too big - 25072 in partition
> > 0xafae8.
> > 0xf2bd0 (CA client): CAS: unable to init the event facility
> >
> > Have we possibly overlooked something in how we use StripTool?
> >
> > Again, from one of Delphy's messages:
> >
> > "There didn't seem to be a relation with the alarm handler, but I'll keep
> > checking. Error messages also print on the Sun about invalid
> > channels that
> > aren't invalid unless the StripTool is running."
> >
> > Any help here with understanding better how channel access works will also
> > be appreciated.
> >
> > Regards,
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > John K. Munro, Jr., PhD
> > Voice: (423) 574-0635
> > Development Staff
> > Pager: (423) 417-6585
> > Instrumentation and Controls Division         FAX: (423) 576-8380
> > Oak Ridge National Laboratory                         Email: [email protected]
> > Bldg. 3500, MS 6010, PO Box 2008
> > Bethel Valley Road
> > Oak Ridge, TN 37831-6010
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >


References:
RE: IOC Errors when StripTool is Running Jeff Hill

Navigate by Date:
Prev: unbundled sequencer v1.9.5 is available William Lupton
Next: Greenspring Octal serial IP question john sinclair
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: IOC Errors when StripTool is Running Jeff Hill
Next: Fwd: alh correction John K Munro Jr
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·