lwip-users
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]