lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #36380] unsent_oversize mismatch in 1.4.1RC1


From: Marco Jakobs
Subject: [lwip-devel] [bug #36380] unsent_oversize mismatch in 1.4.1RC1
Date: Thu, 03 May 2012 19:13:53 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

Follow-up Comment #2, bug #36380 (project lwip):

Hi Simon,

i've spent the evening to test it on my private project at home, and the
behaviour is the same here. I'm suffering random data aborts in weird places
and the described problems as soon as LwIP 1.4.1 is in place.

Unfortunately it won't happen when TCP_OUTPUT_DEBUG is enabled as this is
slowing down the system, preventing the problem from happening.

As a conclusion i suspect a timing / overrun error causing this problem. Here
are some hints:

I notice that i'm often running into a situation in my EMAC where all Tx
Buffers are without a "last block" marking - so i assume that LwIP 1.4.1
writes all available buffers before they can be sent out by the EMAC (using
DMA!). I found my EMAC (SAM7_EMAC.c) here in an endless loop, looking for the
buffer with the "last buffer" marking as it seems to be overwritten (in
vClearEMACTxBuffer).

I'm getting out of that situation now as i'm exiting the while loop in there
as soon as the number of rounds exceeds the number of xTxDescriptors (EMAC Tx
Buffers). There are 24 of these DMA buffers with a size of 128 Bytes each
(3072 bytes in total).

I've also a routine discovering a situation where no empty EMAC buffer is
available when data should be written in there. In this case i'm clearing up
all the Tx buffers (which may cause the loss of a packet) to get a new start
here (otherwise it may lock up in that situation finding no free buffer for
starting up). In real live with a huge traffic this happens every few days one
time with LwIP 1.3.x or 1.4.0 (i'm getting a logger entry then).

With LwIP 1.4.1 this happens quite every few seconds when my logger is running
(my logger puts out all relevant sytem logs, data flow etc. on a TCP
connection, so fast output of a huge amount of data). But is does not happen
with TCP_OUTPUT_DEBUG enabled which slows down the output. After one or two of
these overflows the described ASSERT can be seen.

I've discovered these altered settings in opt.h in 1.4.1:
#define TCP_SND_BUF                     (2 * TCP_MSS)
#define TCP_SNDLOWAT                    LWIP_MIN(LWIP_MAX(((TCP_SND_BUF)/2),
(2 * TCP_MSS) + 1), (TCP_SND_BUF) - 1)
#define TCP_SNDQUEUELOWAT               LWIP_MAX(((TCP_SND_QUEUELEN)/2), 5)


Changing these back to the values from 1.3.x and 1.4.0:
#define TCP_SND_BUF                     256
#define TCP_SNDLOWAT                    ((TCP_SND_BUF)/2)
#define TCP_SNDQUEUELOWAT               ((TCP_SND_QUEUELEN)/2)

makes the situation even worse! The system now immediately produces EMAC Tx
overflow messages and the named ASSERTs as soon as my logger is connected,
causing the TCP data output.

Using the Webserver (ALSO! huge amount of TCP data with fast output) also
triggers these problems!

Using "slow" TCP connections like my Telnet console does not make any
trouble.


Summary:
My feeling is, that something has changed in 1.4.1 causing bad problems as
soon as a big amount of data is put out on a TCP connection. The same output
runs smooth and properly in 1.3.x and 1.4.0. One symptom is that 1.4.1 is
causing many EMAC buffer overruns, which previous versions does not. Due to
small memory i can't exceed the 24x128 Byte EMAC buffers in my system or spend
some memory on other places compared to 1.4.0

I hope this helps, unfortunately the debug output slows the system down to not
cause the problems, so i can't support you with that. But i'll test any
potential fixes of this problem, just report here or contact me on mj at
piciorgros.com.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?36380>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/




reply via email to

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