Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Thu, 18 Mar 1999 15:28:00 -0700

Noboru,

The rumor is that running out of mBufs can cause serious problems
for vxWorks systems. 

I have also heard rumors that if you increase
the maximum number of file descriptors in your system then you must
also increase the number of M buffers for the IP kernel. 

If a client connects, but does not call ca_pend_event() or some other CA routine
to read the CA incoming message queue then it appears that this 
can reserve some number of mbufs until the client disconnects.

Note also that in some of the beta releases of 3.13 the CA client library
will not disconnect from an IOC when the channel count on that IOC goes 
to zero because some of the channels have been deleted (perhaps when a screen 
on the IOC is terminated). This can cause higher than normal resource consumption
(including IP kernel mbufs) until the client process exists. The solution is to
relink the client program {dm, medm, ...} with the R3.13.1 client library
or to stop and restart the client program.

In order to further propagate the mBuf related rumors I have attached an 
E-mail that I saw on the vxWorks mail list concerning this matter.

Jeff

On Wednesday, March 17, 1999 11:11 PM, Noboru Yamamoto [SMTP:[email protected]] wrote:
> Hi,
> 
> Occasionally , we lost CA connectin to the one of IOCs in our system.
> Checking the console log, we found the following messages.
> 
> > 0x15b7fe0 (CA event): CAS: TCP send to "172.19.xx.xx" failed because
> "S_errno_ENOBUFS"
> 
> and
> 
> >iocLogClient: no socket error S_errno_ENOBUFS
> 
> before IOC   was rebooted. First message repeated several times. Then
> several of second message follows.
> 
> In listserve archive, I found the message from J.Hill on similar subjetc.
> 
> File /Public/asd/controls/epics/maillists/tech-talk/199808/19980828.html
> 
> However, It discusses the error messge:
> > 1998-08-27,22:57:08: 0xc2e7d4 (CA UDP): CAS: UDP send to "xx.xx.xx.xx"
> failed
> > because "S_errno_ENOBUFS"
> 
> "TCP sendto" is causing error message in our case, so the discussion in the
> listserve archive may not apply.
> 
> Any suggestion to avoid this message will be greatly appriciated.
> 
> Thank you,
> 
> Noboru Yamamoto
> KEKB control group
> KEK, JAPAN
> 
> 

Newsgroups: comp.os.vxworks
Subject: Re: PCB chain corruption
Date: 14 Jan 99 20:06:23 GMT
From: [email protected] (Georg Feil)
Organization: Centre for Research in Earth and Space Technology 
Message-ID: <[email protected]>
References: <[email protected]>
Next use 'mbufShow' to be sure that there are enough network buffers available. In particular 
the "number of times drained protocols for space"line should show 0, otherwise your system 
has been running out of mbufs.Raise the max mbufs limit and rebuild your VxWorks image to 
get around this.We've found that protocol "draining" can cause serious problems, including 
network access delays and the apparent "stranding" of mbufsresulting in permanent loss 
(this is probably a bug somewhere in VxWorks).
Good luck,Georg- --Georg Feil | 
http://www.sgl.crestech.ca/Space Geodynamics Laboratory | 
Email: [email protected] | 
Phone: (416) 665-54584850 Keele St./North York/Ont/Canada/M3J 3K1 | 
Fax: (416) 665-1815

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System