From: Gary Thomas <gary@mlbassoc.com>
To: Alok Singh <aloks@broadcom.com>
Cc: Andrew Lunn <andrew@lunn.ch>, ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Delay in procesing packet across the BSD stack -
Date: Sat, 02 Jun 2007 14:29:00 -0000 [thread overview]
Message-ID: <46617EA4.7030105@mlbassoc.com> (raw)
In-Reply-To: <FE7FB54DCB7C6949A1D3F9FF22DA6C135DF89D@lvl7in-mail01.lvl7.com>
-----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
next prev parent reply other threads:[~2007-06-02 14:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 23:00 Alok Singh
2007-06-01 23:04 ` Andrew Lunn
2007-06-02 0:16 ` Alok Singh
2007-06-02 0:18 ` Alok Singh
2007-06-02 14:29 ` Gary Thomas [this message]
2007-06-02 15:14 ` Alok Singh
2007-06-04 0:37 ` Alok Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46617EA4.7030105@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=aloks@broadcom.com \
--cc=andrew@lunn.ch \
--cc=ecos-discuss@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).