Cyl -
You may be running out of free memory to allocate and the enternet
buffer is just the place where it shows up.
Short answer:
You may need to look for a memory leak somewhere in your code. These are
no fun to find.
Long answer: eCos sets up a pool of available memory for allocation when
it starts up. This pool is broken into blocks (the 'mbuf's in question, I
think) and when a service or application allocates memory, eCos first
checks whether any space is available in the one or more mbufs already
assigned to that level of your code. If space is available then storage is
allocated from that source for your data object; if not, the memory
manager attempts to get another mbuf to work with. If none is available,
you are "out of MBUFs".
This block-allocation is a common approach in RTOS as it protects memory
allocation and helps keep overhead code under control.
Diagnosis: If you have generous read-write memory available, increase the
amount which is broken up into mbufs at eCos startup. (Sorry - I can't
point you to the correct code at the moment.) If this solves the problem,
you had some kind of worst-case collision. If this makes the problem less
frequent that may still be the issue. It this only delays the problem I
would bet on a memory leak (unbalanced 'malloc' and 'free' usage in some
thread). These are no fun to find.
Suggestions:
1. Inactivate different threads and see if this solves the problem, then
go looking for memory leakage in the thread(s) that were running when the
problem occurred. Recently added code is the prime suspect, of course.
2. Write macros to "wrap" the system's 'malloc' and 'free' code so that
they print from whence they are called and for what objects they are
allocating. Then replace all calls to the system 'malloc' and 'free' with
calls to your macros. (This approach makes it easy to turn the debug code
on and off by at one spot by changing the macros' definitions: through a
compilation switch for example.)
3. Use static rather than dynamic ('malloc') storage allocation wherever
this is practical (not a bad idea in embedded real-time applications that
may need to run stably for indefinite periods.)
4. Use a free ('valgrind') or commercial code analyzer to track memory
allocation (another "learning opportunity"!).
DISCLAIMERS:
1. I don't have eCos code handy so I may be misunderstanding the problem
completely. Sorry.
2. I'm using eCos-2.0 so the issue may be quite different in 3.x.
3. If I missed the boat here, I hope folks will correct me and we will
both learn from it.
- John Mills
On Fri, 16 Jul 2010, cyl cyl wrote:
Hello!
I got warning: eth_recv out of MBUFs, when I was writing to a
connection(frequently) which is NOT NORMALLY closed (hardware is
taken out). Usually "write" returns -1, but sometimes it shows that
message. I'm using ecos3.0 by the way.
Anything will be helpful !
Thank you!
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss