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
- Navigate by Date:
- Prev:
MEDM 2.3.5a Released Ken Evans
- Next:
EPICS web pages at LANL pate
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
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: TCP s_errno_ENOBUFS error in CAS Frank Lenkszus
- Next:
database race condition? Till Straumann
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|