From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14911 invoked by alias); 28 Aug 2007 18:42:38 -0000 Received: (qmail 14711 invoked by uid 22791); 28 Aug 2007 18:42:36 -0000 X-Spam-Check-By: sourceware.org Received: from sccrmhc12.comcast.net (HELO sccrmhc12.comcast.net) (63.240.77.82) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Aug 2007 18:42:31 +0000 Received: from rickmce (c-68-55-175-129.hsd1.md.comcast.net[68.55.175.129]) by comcast.net (sccrmhc12) with SMTP id <2007082818422901200fm20ge>; Tue, 28 Aug 2007 18:42:29 +0000 From: "Rick Davis" To: "'John Mills'" , "'eCos Users'" References: <004701c7e990$9e57b8e0$db072aa0$@net> In-Reply-To: Date: Tue, 28 Aug 2007 18:42:00 -0000 Message-ID: <004e01c7e9a3$2b744650$825cd2f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] network problem X-SW-Source: 2007-08/txt/msg00156.txt.bz2 John, Thanks for the information. On my product it is also the web that is being pounded on and dying. The telnet was used to verify the error. Do you know if there is a way to return these "stale TCP connection records" to the pool? Did you find a fix to the problem? I'm not a network stack expert at all. Thanks again, Rick Davis -----Original Message----- From: John Mills [mailto:johnmills@speakeasy.net] Sent: Tuesday, August 28, 2007 2:10 PM To: eCos Users Cc: Rick Davis Subject: RE: [ECOS] network problem Rick - I have just run to ground a problem with very similar symptoms. It turned out that the 'socket' pool ("zone") was depleted by unrecoverable, stale TCP connection records. I tracked this down by adding a counter for allocated/ deallocated data structures from that pool and diagnostic printouts of the count as sockets were allocated or freed. Though we noticed the problem with web inquiries, it turned out to have other effects - like your inability to open a 'telnet' connection. As I understand eCos 'zones', each is initially allocated a fixed memory block based on the size of a specific data structure and the number of such structures they are expected to provide. Thus a simple counter will reflect where you stand with respect to a particular pool's capacity and you probably don't have to dig into the zone alloc/dealloc mechanism. HTH. - John Mills DISCLAIMER: I'm a relative beginner with eCos. On Tue, 28 Aug 2007, Rick Davis wrote: > Andrew, > > After I sent the e-mail this morning, it stopped working in another way. > http stopped responding but pings still worked. I have a simple telnet > server on my application and it was failing trying to bind with "Try again > later". In_pcbbind was failing because in_pcbinshash was failing indicating > it couldn't MALLOC memory. I turned on fancy asserts and tracing and am > testing again. It usually take 12 Hrs or more to fail. In_pcbhash MALLOCs > from the network pool so I am monitoring that. Any ideas why the network > pool would run out of memory? Can it get fragmented? > > Thanks, > Rick Davis -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss