Hello,

-------- Original Message  --------
Subject: Re:[lwip-users] Lock in tcp_in
From: Simon Goldschmidt <[email protected]>
To: Mailing list for lwIP users <[email protected]>
Date: 07/09/2009 12.59

> You should specificaly pay attention to the timers: they are executed within
> the semaphore/mbox functions (sys_sem_*/sys_mbox_*) and fetch a list of
> timeouts from an arch-dependent function. This list must be per-thread - if
> not, timers will be executed in a wrong thread, which may lead to the
> pcb-list-corruption you saw (by executing tcp_tmr() outside tcpip_thread
> context).

I've already checked that, and it's always a good idea remembering it (initially
I had a similar problem indeed).

I think I've fixed the problem, and yes it was interrupt related.
The original porting I used for the MAC (Xilinx Xemaclite) is heavily affected
by design errors; I tried to not go too much deep with it, and use it a simple
library, but it can be used that way only with a single TCP/UDP port opened at a
time, and very infrequent packets (...)

The interrupt handler was directly using pbuf_alloc(): that alone seems to me
quite dangerous, when pbuf are normally handled by lwIP in an ordinary context
(non-interrupt); working with lwIP only in that interrupt handler would do, but
that's not what I need, nor what they do elsewhere in their code.
Then I buffered ethernet frames independently from lwIP, and passed them
atomically, when running the lwIP task in an ordinary context.

I keep using the (amended) Xilinx's MAC code, and crossing fingers (...)

~ Lou




_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to