From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20600 invoked by alias); 7 May 2007 17:28:04 -0000 Received: (qmail 20589 invoked by uid 22791); 7 May 2007 17:28:03 -0000 X-Spam-Check-By: sourceware.org Received: from mail19c0.megamailservers.com (HELO mail19c0.megamailservers.com) (216.251.36.229) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 May 2007 17:28:01 +0000 X-Authenticated-User: wvisser.lszpaper.com Received: from [192.168.42.101] ([209.171.99.175]) (authenticated bits=0) by mail19c0.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id l47HRquF011338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 May 2007 13:27:56 -0400 Message-ID: <463F6175.5060105@lszpaper.com> Date: Wed, 09 May 2007 19:13:00 -0000 From: Wayne Visser User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Robin Randhawa CC: ecos-discuss@sourceware.org References: <463F213D.6040907@lszpaper.com> <1178552347.17677.8.camel@blackpearl> In-Reply-To: <1178552347.17677.8.camel@blackpearl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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] High priority thread versus network X-SW-Source: 2007-05/txt/msg00049.txt.bz2 Thanks for the tips, Robin. You may be shooting in the dark, but I *am* in the dark! ;-) You're right, it does look like a stack overflow, but I have assertions enabled (CYGDBG_USE_ASSERTS) and CYGFUN_KERNEL_THREADS_STACK_CHECKING is also enabled. I've seen no asserts or panics being raised to date. Are there other assertions I've missed? I'm using a separate interrupt stack (size = 4096). I've gone ahead and increased the size of the NET_THREAD and NET_FAST_THREAD and am currently re-running the tests. -- Wayne Robin Randhawa wrote: > Hi. > > Just some shots in the dark : > > 1. Have you enabled all assertions ? Checks for stack manipulation ? > > 2. Are you using a separate interrupt stack ? > > 3. Does changing the default stack size of the Network Thread make a > difference in either the exhibited phenomena and/or the time before the > system hangs up ? > > The problem you face seems to be a stack overflow but there really isn't > sufficient data to state that as a fact. > > I would try the above just to reduce some of the possibilities. > > Cheers, > Robin > > On Mon, 2007-05-07 at 08:53 -0400, Wayne Visser wrote: >> Hello all, >> >> We're having a problem with an eCos app that has a relatively >> long-running, high priority thread (runs at priority 2 every 10 ms and >> takes about 4ms to complete). Under high network loads, the app will >> crash with no asserts or panics. If the high priority thread is >> disabled, the app will run fine for days without problem under high net >> loads. Conversely, without any networking activity, the app runs fine >> for days. >> >> We've stripped this down to a simple test app with two parts (a) the >> high priority thread basically does nothing but consume CPU time: >> >> static void >> high_thread( cyg_addrword_t arg ) >> { >> int i, j; >> cyg_uint16 buf[1024]; >> >> while (1) >> { >> for ( j=0; j<90; ++j ) >> { >> for ( i=0; i<1024; ++i) >> buf[i] = rand(); >> } >> >> cyg_thread_delay(1); >> } >> } >> >> and (b) several identical networking threads that do nothing but accept >> client connections and echo data sent to them. >> >> If several clients connect to the eCos app, a crash will occur in as >> little as a few minutes (but sometimes hours). >> >> So my question is this: Are there any known issues in running a high >> priority thread with a relatively long running time? i.e. this thread >> is effectively blocking the network threads from running for up to 4ms. >> Will that create any known problems? >> >> Thanks for any feedback. >> >> -- Wayne >> >> >> ps: Out target is i386 and the problem is evident with both 8139 and >> 82559 ethernet drivers. Curiously, the problem does NOT appear with the >> 83816 ethernet driver. >> >> > > . > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss