[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL |
Date: |
Mon, 27 May 2013 19:53:49 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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