RE: [ECOS] Delay in procesing packet across the BSD stack -

["Alok Singh" <aloks@broadcom.com>]

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


regards,
Alok

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Saturday, June 02, 2007 4:35 AM
To: Alok Singh
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Delay in procesing packet across the BSD stack -

On Sat, Jun 02, 2007 at 04:30:00AM +0530, Alok Singh wrote:
> 
> Hi,
> I'm seeing a strange problem on my Box.? I'm using Free BSD stack. The
issue is that when I send icmp requests from a single client to the box,
the stack doesn't respond in time.? But when I start sending icmp
requests from another client, the stack starts sending 100% ICMP echo
replies.? I'm currently debugging the system. I've seen that if I send
echo requests very slowly, then invariably client times out. When I send
icmp request from another client, it sorts of kick something in the
stack, and the echo reply to the previous request packet also comes out.
??
> 
> I'm debugging the system. But if you have some suggestions for me, let
me know.

Check your interrupts are working correctly. It sounds like you are
loosing interrupts, probably TX complete, so the next packet is not
getting sent until the next RX happens.

        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