lwIP shutdown

Altera_Forum · ‎02-07-2006

Hi all,

We're facing serious problems with the lwIP TCP stack. Under some situations, the lwIP threads stop responding and the TCP thread gets blocked.

Because of this we need to make a complete lwIP stack shutdown/restart.

Does anyone know a clean method of doing this?

In order to shut the lwIP stack down, I have modified some files (altera_avalon_lan91c111.c, sys_arch.c, sockets.c) to keep track of the mailboxes, semaphores and threads created by the lwIP to destroy them. I also put in reset condition the lan91c11 chip and remove it's interrupt handler.

After trying to relaunch the lwIP stack (using DHCP for IP address assignment), the stack thread gets blocked in the following line from pbuf.c:

LWIP_ASSERT("p->len < p->tot_len", p->len < p->tot_len);

Does anyone have an idea of what could be the cause for this error?

Thanks a lot in advance,

p.d. I use:

- lwIP 1.1.0 (downloaded from the savannah project download site);

- lan91c111 chip MAC&PHY;

- Quartus II 4.2;

Altera_Forum · ‎02-07-2006

Hi VLorenzo,

concerning the first problem (lwIP threads stop responding) we noticed that in some situations the lwip threads could deadlock.

In fact the lwip stack uses a certain number of semaphores to synchronize execution between threads and more than one semaphore can be locked by the same thread in succession. But instead of simply locking on the semaphore, the sys_sem_wait function is designed to cyclically call the lwip's 'timeout' callbacks while it waits that the semaphore is released.

I don't remember the details, but essentially it could happen that a (user) thread already owns a semaphore (for example the ARP table one) and tries to catch another semaphore (for example the pbuf pool semaphore), already locked.

While waiting for that semaphore, the timeout callback functions could call some code that tries to get the first semaphore (the ARP table one in the example) and... the deadlock is served!

The workaround was to modify the sys_sem_wait function in order to simply call the sys_arch_sem_wait, i.e:

void sys_sem_wait(sys_sem_t sem)
{
 sys_arch_sem_wait(sem,0);
}

Perhaps we should have posted it also to the lwIP official forum, because it looks very much like a bug.

For the second problem (the LWIP_ASSERT):

sometimes we had this assert (and more often the other assertion "pbuf_free: p->ref > 0") before patching the CPU for the 'data cache bug' that I already discussed in another thread (thread title: "uC/OS-II LWIP pbuf_free fail"). After patching the CPU we never had an assertion from lwIP anymore.

However this could be caused also by the stack shutdown/restart process...

--- Quote Start ---

originally posted by vlorenzo@Feb 7 2006, 04:42 PM

hi all,

we're facing serious problems with the lwip tcp stack. under some situations, the lwip threads stop responding and the tcp thread gets blocked.

because of this we need to make a complete lwip stack shutdown/restart.

does anyone know a clean method of doing this?

in order to shut the lwip stack down, i have modified some files (altera_avalon_lan91c111.c, sys_arch.c, sockets.c) to keep track of the mailboxes, semaphores and threads created by the lwip to destroy them. i also put in reset condition the lan91c11 chip and remove it's interrupt handler.

after trying to relaunch the lwip stack (using dhcp for ip address assignment), the stack thread gets blocked in the following line from pbuf.c:

lwip_assert("p->len < p->tot_len", p->len < p->tot_len);

does anyone have an idea of what could be the cause for this error?

thanks a lot in advance,

p.d. i use:

- lwip 1.1.0 (downloaded from the savannah project download site);

- lan91c111 chip mac&phy;

- quartus ii 4.2;

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12605)

--- quote end ---

--- Quote End ---