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

[Sebastian Gonzalez]

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?

Best regards.

Sebastian
 



--
View this message in context: 
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461.html
Sent from the lwip-users mailing list archive at Nabble.com.