public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Marco Monguzzi" <marco@sitek.it>
To: <ecos-discuss@sourceware.cygnus.com>
Subject: [ECOS] problems with MBUFs (TCP/IP stack)
Date: Sat, 08 Jul 2000 05:54:00 -0000	[thread overview]
Message-ID: <NCBBKIOHEKNFDFBEBPNHOEELDOAA.marco@sitek.it> (raw)

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

Hello All.

we are running eCos (with the TCP/IP package) on a MIPS R3041 based board.
The board is equipped with a CS8900A ethernet controller. The ethernet
driver has been written starting from the one that comes for the EDB7xxx
board.

Althought the Net subsystem passed all the package's tests, we are
experiencing severe problems with MBUFs handling. They are driving out of
time our project delivery date. Any help would be more than welcome...

It is possible to explain the problem using a simple program: attached
you'll find the eCos "server test" (file server_test.c) modified to show the
MBUF counter for each incoming connection. Each time we connect to the
server with telnet, the counter becames bigger (one more than the previous
iteration). Repeating the trial several times (around 60 times), we get the
signaling of "panic: eth_recv out of MBUFs" (with the net v1_0b1 package).
We also tried with a snapshot of the net package from CVS (downloaded on
June 6, 2000. We patched kapi.h and kapi.cxx to support
cyg_scheduler_safe_lock() and cyg_scheduler_read_lock()); the system now
tolerates the problem and does not halt but the behavior is the same:
"warning: eth_recv out of MBUFs".

We captured the packets exchanged between the server (192.168.0.116) the
client used to run telnet (a Linux box. 192.168.0.10). You'll find them
attached in packets.zip.

Notice: commenting the write() in server_test.c (line 115), i.e. we do not
send back the string "hello etc..", the MBUF counter does not show this
behaviour any more. It seems like the mbufs are not freed from the TCP
queue.

Anybody experienced something similar? Any suggestion about how we should
tackle this problem?

All the best,
Marco

[-- Attachment #2: packets.zip --]
[-- Type: application/zip, Size: 2222 bytes --]

[-- Attachment #3: server_test.zip --]
[-- Type: application/zip, Size: 1942 bytes --]

             reply	other threads:[~2000-07-08  5:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-08  5:54 Marco Monguzzi [this message]
2000-07-08  8:26 ` Grant Edwards
2000-07-08 11:45   ` Marco Monguzzi
2000-07-08 12:05     ` Marco Monguzzi
2000-07-10  8:50     ` Grant Edwards
2000-07-10  9:53       ` Gary Thomas
2000-07-10 10:21       ` Marco Monguzzi
2000-07-10 10:33         ` Grant Edwards
2000-07-10 10:41         ` Gary Thomas
2000-07-10 11:18           ` Marco Monguzzi
2000-07-10 13:03       ` Grant Edwards
2000-07-11  3:45         ` Hugo 'NOx' Tyson
2000-07-11  8:38           ` Marco Monguzzi

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=NCBBKIOHEKNFDFBEBPNHOEELDOAA.marco@sitek.it \
    --to=marco@sitek.it \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /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).