|
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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users --
|
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
