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

[Richard dot von dot Lehe at gd-ais dot com]

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.

Rich



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