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:
Hi!
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
messages.
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
warnings.
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.
Regards,
Kjell-Erik
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
--
Jim Gibbons
|
address@hidden
|
Gibbons and Associates, Inc.
|
TEL: (408) 984-1441
|
900 Lafayette, Suite 704, Santa Clara, CA
|
FAX: (408) 247-6395
|
|