Hi Sylvain,
Thank you for your inputs. I have checked the files that you sent
and this issue is covered in my driver.
Based on my tests it looks like a race condition on the receive
path. Pbufs are allocated in the etherif layer and passed to an
upper layer for processing, this upper layer does not free the
pbufs, not because of a memory leakage, just because it can't (i.e.
IP defragmenting).
At some point when the traffic rises the upper layer requires more
packets in order to complete frames and release the pbufs, and the
etherif layer can not allocate more pbufs because it has ran out of
memory, so they come to a deadlock.
How can I break it? If I close every socket of my application layer
will it make it?
Best regards.
Sebastian.
El 27/05/2013 19:54, Sylvain Rochet
[via lwIP] escribió:
Hi Sebastian,
On Mon, May 27, 2013 at 10:01:44AM -0700, Sebastian Gonzalez
wrote:
> Hi,
>
> I am using lwIP 1.3.2 with an Atmel AT91SAM7X512, and
FreeRTOS. We have
> already used this combination in other projects with no
problem, but now we
> using our design in a network with high density of UDP
broadcast traffic
> causing the system to stop receiving.
> The transmission path keeps working as I can see ARP
request messages coming
> out in the wireshark traces.
> After debugging and searching I found that several people
had the same
> issue: The pbuf_alloc call from low_level_input in the
ethernet driver
> returns NULL during the packet storm and keeps returning
NULL, as if the
> TCP/IP task wasn't fast enough to free the pbufs, and
thus the packets from
> the EMAC do not move to the upper layers.
> I do understand that during a packet storm all the
packets that can't be
> processed are dropped, actually that's the behaviour that
I expect. But I
> don't get why the consumer process is unable to free the
packets that have
> already been passed to the upper layer.
> I have tried giving the TCP/IP thread the higher priority
with no results.
> Also changed the number of pbufs from 8 to 16 and noticed
that the problem
> happened later in time.
> Is there a recommended value for the number of pbufs,
considering my reduced
> schema of memory?
As usual, looks like a bug in the MACB driver, you have to check
carefully if the lwIP pbug get free()d whatever is happening along
the
input and output path.
I can't talk about the AT91 MACB driver, but the AT32 MACB driver
suffer
a huge bug about that, it only free()s MACB TX buffers of
successfully
sent frames, which ends up by locking the TX path, RX path is
still live
and is allocating all pbuf.
void vClearMACBTxBuffer(void) {
// The first buffer in the frame should have the bit set
automatically. */
if( xTxDescriptors[ uxNextBufferToClear ].U_Status.status
& AVR32_TRANSMIT_OK ) {
[...]
}
}
"Before a transmission, bit 31 is the "used" bit which must be
zero
when the control word is read. It is written to one when a
frame has
been transmitted."
Guess what happens if the "transmit ok" bit is not set and the
"should
have the bit set" ... going to be false :>
If it helps, I attached my patch against the AT32 MACB driver
which
helps the system to recover, maybe the AT91 driver is similar. The
patch
is not perfect, because it drops all queued frames, which I
consider
adequate because it only happens a few times per week on a very
very
loaded ethif.
Sylvain
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
at32-macb-fix-non-free-pbuf-on-failed-tx-frame.diff
(2K) Download
Attachment
signature.asc
(205 bytes) Download
Attachment
If you reply to this email, your
message will be added to the discussion below:
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21463.html
To unsubscribe from Receive path stuck due to pbuf_alloc
returning NULL, click
here .
NAML
--
Firma By
Sebastián González
Investigación y Desarrollo
Tlf: 902 82 00 82
Fax: 902 82 00 83
[email protected]
www.by.com.es
Antes de imprimir este e-mail piense si realmente es necesario
hacerlo, el medio ambiente se lo agradecerá.
ADVERTENCIA
La información contenida en este correo
electrónico, es
de carácter privado y confidencial, siendo para uso
exclusivo de su destinatario. Si usted no es el
destinatario correcto, o ha recibido esta comunicación
por error, le informamos que está totalmente prohibida
cualquier divulgación, distribución o
reproducción de
esta comunicación según la legislación
vigente y le
rogamos que nos lo notifique inmediatamente, procediendo
a su destrucción sin continuar su lectura.
Su dirección de correo electrónico, así
como el resto de
los datos de carácter personal que nos facilite,
podrían
ser objeto de tratamiento automatizado en nuestros
ficheros, con la finalidad de gestionar la agenda de
contactos de BY TECHDESIGN,S.L. Vd. podrá en cualquier
momento ejercer sus derechos de acceso, rectificación,
cancelación y oposición según la Ley
Orgánica 15/1999
mediante notificación escrita a la siguiente
dirección:
CALLE TOMAS EDISON 5 28500 ARGANDA DEL REY.
LogoBy.jpg (3K) <http://lwip.100.n7.nabble.com/attachment/21467/0/LogoBy.jpg>
--
View this message in context:
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21467.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
