lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] FTP-DATA exchange: TCP issues


From: Tom C. Barker
Subject: RE: [lwip-users] FTP-DATA exchange: TCP issues
Date: Wed, 9 Mar 2005 08:32:06 -0800

Tim,

Thanks for your response. You are describing the 
same basic reentrancy I am getting. Even though
I have SYS_LIGHTWEIGHT_PROT enabled, the call tree
goes 

  tcp_write(...)  
  tcp_enqueue(...)
  pbuf_alloc(...)
  mem_malloc(...)
  sys_sem_wait(mem_sem);
  
at which point, the slow_tmr is found to have expired 
and a (reentrant) _poll call is made.

I have recrafted my _poll methods to perform one write
and then set a flag to never write again from _poll(). The
first write is needed to get the transmission going.

Thanks again,
Tom







-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of address@hidden
Sent: Wednesday, March 09, 2005 1:13 AM
To: address@hidden
Subject: RE: [lwip-users] FTP-DATA exchange: TCP issues






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 mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users




reply via email to

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