This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eth_recv out of MBUFs


Hello:
        A strange thing.   If I twice the "MBUFs memory size" which is
69632  to 139264,  it seems worse.  No warnings of "out of MBUFs" ,
but a few seconds after I took out the hardware (my computer not the
development board) , I can't ping it (from another computer).
        If I set the "MBUFs memory size" to 69632 (default value), the
same problem occurs . But not happens so soon as "139264".
        If set to 34816 (half). It works well. I can always ping its
ip. And the "write" to the "unnormally closed" connection would return
-1 at last.
        if set to 17408 (1/4), the warning out of MBUFs occurs.
        Any suggestions?
Thank you.

- cyl


2010/7/17 John Mills <johnmills@speakeasy.net>:
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]