Dear Ivan,
I had some issues with the driver that had to be debugged as well,
adding AT91C_EMAC_ROVR and AT91C_EMAC_RXUBR as interrupt sources
for example, in order to signal an overrun in the ISR. Apart of that
my handler looks pretty much like yours.
The number of messages that could be queued was 6 as well in my code
Vs. 8 pbufs. Provided that the messages/packets are used for
incoming packets and other messages to the thread this number was
definitely wrong. Changed it to 16 and testing looks good.
I'll try this solution a couple of days.
Thank you so much.
Best regards.
Sebastian.
El 28/05/2013 18:06, Ivan Delamer-2
[via lwIP] escribió:
Hello Sebastian,
The example AT91 port from FreeRTOS has some issues that show up
in
large traffic scenarios, typically with many UDP broadcasts or
multicasts, but could also be caused by high volume TCP.
I have optimized the driver in many ways so I don't remember
exactly
the changes I made to fix this, but it was something like this:
- When pbufs are allocated in ethernetif.c, there are some
conditions
where the packets aren't freed properly (if not an IP packet?).
this led
to a memory leak.
- Sometimes there are not enough memp messages to pass
packets/messages
to the tcpip thread. I increased this from 6? to 20.
There is also sometimes some unexpected behaviors from the AT91
EMAC
when receiving packets really fast, so for example if you are in
the IRQ
for sending and then you receive something during, you need to
take
care. My ISR looks like this:
void vEMACISR_Handler( void )
{
volatile unsigned portLONG ulIntStatus __attribute__ ((unused));
volatile unsigned portLONG ulTxStatus;
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
/* Find the cause of the interrupt, cleared on read.
*/
ulIntStatus = AT91C_BASE_EMAC->EMAC_ISR;
if ( AT91C_BASE_EMAC->EMAC_RSR &
AT91C_EMAC_REC )
{
/* A frame has been received, signal
the lwIP task so it
can
process
the Rx descriptors. */
AT91C_BASE_EMAC->EMAC_RSR =
AT91C_EMAC_REC;
xSemaphoreGiveFromISR( xSemaphore,
&xHigherPriorityTaskWoken );
}
ulTxStatus = AT91C_BASE_EMAC->EMAC_TSR;
if( ulTxStatus & AT91C_EMAC_COMP )
{
/* A frame has been transmitted.
Mark all the buffers
used by
the
frame just transmitted as free again. */
AT91C_BASE_EMAC->EMAC_TSR =
AT91C_EMAC_COMP;
vClearEMACTxBuffer();
}
if( ulTxStatus & (AT91C_EMAC_UND |
AT91C_EMAC_BEX))
{
/* A frame Tx failed. Reset Tx buffers.
*/
AT91C_BASE_EMAC->EMAC_TSR =
AT91C_EMAC_UND |
AT91C_EMAC_BEX;
EMAC_Statistics.tx_errors++;
vResetEMACTxBuffer();
}
/* Clear the interrupt. */
AT91C_BASE_AIC->AIC_EOICR = 0;
/* If a task was woken by either a frame being
received then
we may
need to
switch to another task. If the unblocked task
was of higher
priority then
the interrupted task it will then execute immediately
that
the ISR
completes. */
if( xHigherPriorityTaskWoken )
{
portYIELD_FROM_ISR();
}
}
/*-----------------------------------------------------------*/
void vEMACISR_Wrapper( void )
{
/* Save the context of the interrupted task. */
portSAVE_CONTEXT();
/* Call the handler to do the work. This must
be a separate
function to ensure the stack frame is set up
correctly. */
vEMACISR_Handler();
/* Restore the context of whichever task will execute
next.
*/
portRESTORE_CONTEXT();
}
I hope this helps. I've struggled a lot when moving from
low-traffic
lab network to high-traffic production network.
Cheers
Ivan
> Date: Mon, 27 May 2013 10:01:44 -0700 (PDT)
> From: Sebastian Gonzalez < [hidden email] >
> To: [hidden email]
> Subject: [lwip-users] Receive path stuck due to pbuf_alloc
returning
> NULL
> Message-ID: < [hidden email] >
> Content-Type: text/plain; charset=us-ascii
>
> 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.
>
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
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-tp21461p21475.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/21476/0/LogoBy.jpg>
--
View this message in context:
http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21476.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
