Gary,
I'm sending the patch. Please do a diff against current or v2_0 code to
capture the differences. 
Location of the file: packages/net/bsd_tcpip/v2_0/src/sys/net

Testing - This is simple to reproduce. 
Please make sure that no other traffic except the test traffic goes to
the stack.  Now send a single test ping packet(from test client m/c) to
the Device under test(DUT). You shouldn't see the reply packet. And that
is the issue. Send the next echo request packet, and you should see the
response to the first echo request packet. You can additionally add
static ARP of the DUT on the client m/c and vice-versa. This will make
sure that no other packet exchanges, other than test traffic occur b/w
the DUT and client m/c.  
This should reproduce the problem. 

Please Let me know if my description is insufficient. I'll try to send
more details then.   

regards,
Alok
-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com] 
Sent: Saturday, June 02, 2007 7:59 PM
To: Alok Singh
Cc: Andrew Lunn; ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Delay in procesing packet across the BSD stack -

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alok Singh wrote:
> My network support thread is running at priority 7.

Please send a patch so we can see what you've actually done.
Also, a full description of how to duplicate the failure would be good.

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Alok
Singh
> Sent: Saturday, June 02, 2007 5:46 AM
> To: Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Delay in procesing packet across the BSD stack -
> 
> Andrew,
> 
> I don't say it's a bug, but worth while to take a look at. My problem
is
> solved, when I made certain modifications in BSD stack. 
> 
> In ether_demux(), we call schednetisr(NETISR_IP) for IP packet( or for
> that matter for any type of packet) before enqueuing the packet, by
way
> of calling IF_ENQUEUE(inq, m). ENQUEUE will be done only at the end of
> the ether_demux().  So cyg_netint() waiting via cyg_flag_wait() will
> come alive, and calls corresponding ISR, that is ipintr() for our
case.
> It will try to dequeue the packet, but finds none, because enqueue is
> not done still.
> 
> I changed the logic to call schednetisr() after enqueuing the packet.
> And things work fine.
> 
> Now it is really strange why others don't see the problem. May be some
> other conditions match for others, that don't match for me.
> 
> But I think what I'm doing is logical correct. Am I allowed to make
> these changes to my ecos??
>