Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL

[Sebastian Gonzalez]

    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

--

---

Sebastián González
Investigación y Desarrollo
Tlf: 902 82 00 82
Fax: 902 82 00 83

[hidden email]
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.

---

View this message in context: Re: Receive path stuck due to pbuf_alloc returning NULL
Sent from the lwip-users mailing list archive at Nabble.com.