[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP 1.1.0 stability issue

From: Jim Gibbons
Subject: Re: [lwip-users] LWIP 1.1.0 stability issue
Date: Tue, 23 Aug 2005 09:10:14 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

I'm not so good at answering, so be nice to me, too :-)

First, as regards the error that you cite.  It really looks like your memory pool is small for the traffic that you are running.  This can be a big-ish topic.  lwIP contains mem_malloc and some related functions that are capable of allocating from completely private memory areas.  These are statically allocated in the code, based on sizes that are typically declared in lwipopts.h.  (There are probably default sizes in opt.h, as well.)   It is possible to re-direct mem_malloc and its related functions to others in your own system.  So, for example, if you are already running with a big heap, you might prefer not to use a private allocation interior to lwIP.

Whatever choice you do make about mem_malloc, it will be used in write requests.  When you call the standard write functions, you are using a buffer of your own for the write data.  The data will be transcribed from there into a pbuf, which in its turn will have its memory buffer allocated via mem_malloc.  It looks like you ran out.  You've got some other tuning options in lwIP aside from the memory pool size, so you might want to look these over as you decide how to deal with this issue.  For example, you may choose to limit your send buffer sizes instead of increasing your memory pool.  Again, look in lwipopts.h for installation choices and in opt.h for defaults.

As regards the timers, they should be running in the context of the tcpip_thread.  If they aren't, then you definitely have a problem.  In older versions of lwIP, this was accomplished by making a sys_timeout call to start the timer from "done" function that was passed into tcpip_init.  That "done" function is called from the tcpip context, so this gets the timer going properly.  Once it's started, it's easy to keep it running in the correct context.  I think that some of this has changed (for the better) in 1.1.0, but I can't remember the exact scheme that is now used.  If you can find the code initializing your stack, you should be able to track it down.

Kjell-Erik Klevan wrote:

This is my first email to this forum so be nice to me :-)

We have an IP input board equipped with a TI DM642 DSP running the LWIP
version 1.1.0 stack. More, the board contains two Intel gigabit Ethernet
controllers. One that communicates with the outside world and one that only
communicates internally with other boards in the unit (typically data
processor boards).

We have some stability issues with the LWIP stack and are easily provoked
during FTP test (upload and download of files). When it occurs, the board
does not respond even to ping. However, it still transmits and receives ARP

During test, we encountered the following printouts:
Closing data socket 23
mem_malloc: could not allocate 1096 bytes
tcp_enqueue : could not allocate memory for pbuf copy size 1024

Note that this is only one way for us to provoke it. It also happens
sometimes with other TCP applications (like Telnet) but without any

Looking more through the code I started wondering about the TCP part of the
stack. tcp_active_pcbs variable that keeps track of the list of active TCP
connections is not protected by any semaphore. The timer function
"tcp_slowtmr" and the thread "tcpip_thread" are both using this list. To me,
it seems that this list can be corrupted if no semaphore protection is
added. OR is it something that I am missing here?

Thanks for any help or guidelines you can give.


lwip-users mailing list

Jim Gibbons
Gibbons and Associates, Inc.
TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
FAX: (408) 247-6395

reply via email to

[Prev in Thread] Current Thread [Next in Thread]