I don't really get which function you are talking about, but if the
input mbox is full (thus a received pbuf cannot be passed from the
driver to lwIP), of course it has to be freed by someone. Normally, the
function passing the pbuf to the mbox would return an error that would
allow the driver freeing the pbuf.
This situation (receive-mbox too full) is perfectly normal for systems
that cannot handle packets at wire-speed.
Simon
Alexandre Malo wrote:
Hi,
I am having PBUF starvation. After a time, some PBUF isnt freed and
will never be. I believe, after debuging and adding trace to the pbuf
file that it is cause by the TCP_INPUT function. I'm using TCPIP thread.
Im keeping a list of allocated pbuf pointer with a time of allocation.
With this list I found that many PBUF were not freed and remain
allocated. All the threads are running correctly.
I think the problem is located in TCP_INPUT. When the mbox of TCP
thread is full, the pbuf isn't freed. Should the PBUF be freed there
or should it be my FEC port that free the pbuf?
struct tcpip_msg *msg;
if (mbox != SYS_MBOX_NULL) {
msg = memp_malloc(MEMP_TCPIP_MSG_API);
if (msg == NULL) {
return ERR_MEM;
}
msg->type = TCPIP_MSG_CALLBACK;
msg->msg.cb.f = f;
msg->msg.cb.ctx = ctx;
if (block) {
sys_mbox_post(mbox, msg);
} else {
if (sys_mbox_trypost(mbox, msg) != ERR_OK) {
// FREE THE PBUF HERE??? //
memp_free(MEMP_TCPIP_MSG_API, msg);
return ERR_MEM;
}
}
return ERR_OK;
}
return ERR_VAL;
Thanks!
------------------------------------------------------------------------
_______________________________________________
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
