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.
.