Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Tue, 15 Feb 2000 14:25:40 -0700

>
> "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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System