[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] FTP-DATA exchange: TCP issues
From: |
tbutler |
Subject: |
RE: [lwip-users] FTP-DATA exchange: TCP issues |
Date: |
Wed, 9 Mar 2005 10:13:25 +0100 |
Tom,
I used to utilize both the tcp_poll and tcp_sent callbacks to drive the
continuation of transmission of data, but I ran into reentrancy problems.
In my case, it was due to the fact the during the course of its output
processing, LWIP calls sys_sem_wait(), which in turn executes the
per-thread timer logic (in the same fashion as the call to sys_mbox_fetch()
in the main loop of the TCPIP thread). If sys_sem_wait() happened to detect
a timeout, tcp_tmr() would execute, thereby reentering the TCPIP thread
logic. When this resulted in a call to tcp_poll(), all of my transmit logic
was reentered, which was where I happened to detect the ill effects of the
reentrancy. My solution was to simply stop using tcp_poll to do any
sending.
I'm not sure if this is the same problem you're experiencing; the use of a
semaphore during the TCP output processing could be due to the fact that I
have SYS_LIGHTWEIGHT_PROT disabled, which results in the use of a semapore
in the memory pool/Pbuf logic.
Tim
"Tom C. Barker" <address@hidden>@nongnu.org con fecha 08/03/2005
20:30:41
Por favor, responda a Mailing list for lwIP users <address@hidden>
Enviado por: address@hidden
Destinatarios: "Mailing list for lwIP users" <address@hidden>
CC:
Asunto: RE: [lwip-users] FTP-DATA exchange: TCP issues
The issue is that my polling function was
trying to send data. Has anyone ever implemented
a poll function which sends data? You'd have
to have a semaphore from my current experience,
right? All comments welcome. Here's what I found.
When the polling function sends data it could and
did become reentrant in tcp_enqueue. With some added
debug statements shown below, when the alloc is called
and we have to wait, the tcp_slowtmr: begins another
call to FTP: ftp_retreiveFile_poll... In combination
with an optimized compiler, the pcb->snd_lbb in the regs
gets off by one and the transfer becomes corrupted.
FTP: ftp_retreiveFile_poll at pcb 0x110b4bf8
tcp_write(pcb=0x110b4bf8, arg=0x1109bd14, len=2920, copy=1)
tcp_enqueue(pcb=0x110b4bf8, arg=0x1109bd14, len=2920, flags=0, copy=1)
TCPOUT_enter: pcb->snd_lbb = 242214
tcp_enqueue: queuelen: 9
TCPOUT_allocing: start in thread Lwip/TCPIP-InputSem.
TCPOUT_allocing: end in thread Lwip/TCPIP-InputSem.
tcp_enqueue: queueing 242214:243674 (0x0)
**TCPOUT_allocing: start in thread Lwip/TCPIP-InputSem.
tcp_slowtmr: processing active pcb
...
tcp_enqueue: queueing 243674:245134 (0x0)
TCPOUT_exit: pcb->snd_lbb = 248054
lbb should be 245134 but here it shows as 248054!
Tom
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
- [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/03
- RE: [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/04
- RE: [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/04
- RE: [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/04
- RE: [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/08
- RE: [lwip-users] FTP-DATA exchange: TCP issues,
tbutler <=
- RE: [lwip-users] FTP-DATA exchange: TCP issues, Tom C. Barker, 2005/03/09