[ECOS] basic misunderstanding of GDB stubs / network stack?

Andrew Lunn andrew@lunn.ch
Tue Jul 13 07:27:00 GMT 2004


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



More information about the Ecos-discuss mailing list