Hello,
Recently we found a problem in our product. After some times we
found that we had a reentrency problem within mem.c module.
In our application when sending data to our Ethernet driver, the
driver call pbuf_ref(p) for each pbuf it receives then in the TX
ISR handler, it calls pbuf_free(p). On the receive side, RX
interrupt simply set a flag telling that some packets are waiting
for service. I believe a lot of people here are using this kind of
mechanism.
So beside the TX End ISR handler which only call pbuf_free as
necessary, all other parts of the stack are running at normal level
(ie not interrupt level). So there is effectively only one thread
for the stack. We dont have an OS (NO_SYS = 1) but
SYS_LIGHTWEIGHT_PROT = 1. Stack version is currently 1.1.1, but
latest CVS version still exhibit this behavior.
Our problem :
We are receiving a lot of data (70MB/s rate on Gigabit interface),
so the stack send a lot of ACK.
For each ACK, pbuf_alloc() is called, with pbuf flag as PBUF_RAM =>
mem_malloc is called, imagine at this point we have a TX Done
interrupt, as no SYS_ARCH_PROTECT(lev) was called, the task is
interrupted
TX Done Interrupt :
we call pbuf_free(p) in our interrupt handler, which in turn call
mem_free and cause our problem because we end up with
inconsistencies with Heap management. Typically this fire an ASSERT
in a subsequent mem.c function.
In the source code, you can see that there was some protection in
the form of sys_sem_wait/sys_sem_signal, but as previously
mentioned, we don't use OS Primitives.
The solution of this problem, once found was simply to add
SYS_ARCH_PROTECT protection mechanism as an alternative to
sys_sem_xxx function already present. The generic form is :
#if SYS_LIGHTWEIGHT_PROT
SYS_ARCH_PROTECT(level)
#else
sys_sem_wait(mem_sem)
#endif /* SYS_LIGHTWEIGHT_PROT */
I want to have your advice to known if it's something that must be
corrected (I believe so), or left as is.
Thanks,
Fred.
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users