This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: 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??
>
>
> 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
>
>
>
- --
- ------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGYX6jmaKbSsQGV8ARAhwNAKCerN1cTH6R2tRWRjsCZqrMCBhQeACfeh+R
zEXijSkDMZsJpDKrAYQjR7w=
=RumZ
-----END PGP SIGNATURE-----
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss