[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Lock in tcp_in
From: |
Lou Cypher |
Subject: |
Re: [lwip-users] Lock in tcp_in |
Date: |
Tue, 08 Sep 2009 09:30:13 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
Hello,
-------- Original Message --------
Subject: Re:[lwip-users] Lock in tcp_in
From: Simon Goldschmidt <address@hidden>
To: Mailing list for lwIP users <address@hidden>
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