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

[Sylvain Rochet]

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

at32-macb-fix-non-free-pbuf-on-failed-tx-frame.diff
Description: Text Data

signature.asc
Description: Digital signature