[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Abnormal Tx delays

From: Ofer Epstein
Subject: RE: [lwip-users] Abnormal Tx delays
Date: Fri, 21 Sep 2007 16:09:42 +0200


Thanks for your reply.

I understand that in your Rx task you tried to read only one packet from Rx FIFO following Rx interrupt?

Did you disable/enable interrupts in your Rx task?



From: address@hidden [mailto:address@hidden On Behalf Of Nicolas Pinault
Sent: Friday, September 21, 2007 2:07 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Abnormal Tx delays


I am interested in further details regarding the driver problem you have had. I think I also have a MAC driver problem.

It looks like the MAC stops sending frames suddenly and this is causing the lwip stack to deadlock while waiting to TX DONE IRQ.

I managed to force tx restart on the MAC and this "fix" the deadlock but with a big performance penalty, so it's is not a real solution.

I use a TALITY MAC driver.

Please let me know your experience with your MAC driver.

The problem with the MAC I use is on the Rx Interrupt side since I don't use Tx interrupt.
The KSZ8841 has a MAC with a Rx FIFO wich can contain several packets.
When a received packet matches all filter conditions, it is transfered into the fifo and an interrupt is generated.
My interrupt handler only signals a semaphore.
My Rx task waits on this same semaphore, reads Interrupt status and clears interrupt status. If Rx is signaled in Interrupt status, then the packet is read from Rx FIFO.
The problem arises when 2 or more Rx packets are stored in Rx FIFO before Rx task can react to interrupts (thru semaphore).
For example :
- One packet is stored in Rx FIFO, an interrupt is trigered and the semaphore is signaled.
- Another packet is stored in Rx FIFO, another interrupt is trigered and the semaphore is signaled again.
- Rx task gets the semaphore, reads the interrupt status, clears the interrupt status and reads the packet fron the Rx FIFO.
- Rx task gets the semaphore again reads the interrupt status and... do nothing since the interrupt status does not signal a Rx packet event.

I expected the interrupt status flag to be still signaling a Rx packet in FIFO since a Rx packet IS in the FIFO.

Now, if, say, 10 seconds later a new packet is stored in the Rx FIFO, all the process executes well but... reads the packet that has been received 10 seconds earlier. The new received packet will be read when another packet is received.
This way, a ping response can be sent seconds after the request.

Lwip is not faulty.


DSP Group LTD. automatically scans all emails and attachments using MessageLabs Email Security System.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]