This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: basic misunderstanding of GDB stubs / network stack?


I had not properly initialized the pthread attribute structure and it was overrunning its stack.  Turning on ASSERTS identified that there was indeed an error and then setting the stack size properly solved the problem.

It's so nice when things make sense.

Thanks,
Rich

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Tuesday, July 13, 2004 2:28 AM
To: von Lehe, Richard H
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] basic misunderstanding of GDB stubs / network stack?


On Mon, Jul 12, 2004 at 06:55:13PM -0500, Richard.von.Lehe@gd-ais.com wrote:
> Hi,
> 
> I've been playing with ethernet interface settings on a Rattler board and have an observation.  Tell me if my thinking is correct or not.  
> 

> In my main routine I configure both interfaces, changing the IP
> address from that stored in flash by Redboot.  This works just fine.
> Then I call pthread_create and call pthread_join immediately after.
> In my thread function, I call a blocking socket function
> (recv_from).  So my main thread and my created thread are both in
> blocking functions.  I then get messages like 'ignoring packet
> error' from GDB, which leads me to believe that the GDB stubs
> interface is getting starved and my PC is getting no response.
> Also, the board doesn't respond to pings on either the Redboot IP
> address or the application's new address.  To back this up, if I
> change my main and my thread to just sit in endless loops calling
> sleep(1), things are OK and I can ping my rattler board on the new
> IP address.
>
> If I am right, then I'm not sure how I should avoid this.  Isn't
> there a thread created automatically that handles network things
> like ARP requests?  Doesn't the kernel have a way of executing the
> network stack and GDB stubs code without requiring cooperation from
> the application and its threads?  Any advice is appreciated.

The network stack will run so long as there is no higher priority
thread which is runable. Since your two other threads are not runable
the network stack should get to run. 

Try making your stacks bigger would be my first suggestion. It could
be you have over run the stacks and stomped on something important for
the network. Also enable assertion checking by turning on INFRA_DEBUG.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]