Re: [lwip-users] TCP retransmission flooding at end of stream

[Jens Nielsen]

Hi

Just to clarify, there are two flavours of the STM bug:

The first and most common one is where you receive one packet that triggers an 
interrupt, and before the rx thread wakes up and services the packet you get 
another packet and triggers a new interrupt. Since ST only used a simple 
semaphore and services one packet per "taken semaphore" you would miss the 
second packet. This can be solved with a counting semaphore.

The second and more obscure bug is where you receive one packet but before the 
interrupt flag is cleared you receive another packet. I.e. you will only get 
one interrupt for two packets, in that case your counting semaphore will only 
be given once and (assuming you still have the "service one packet per taken 
semaphore" code) you will only service one packet. My solution to this was to 
loop and poll DMA for several packets each time the rx thread wakes up. (and by 
doing this you actually don't need a counting semaphore)

BR /Jens


>----Ursprungligt meddelande----
>Från: address@hidden
>Datum: 2014-09-18 13:30
>Till: <address@hidden>
>Ärende: Re: [lwip-users] TCP retransmission flooding at end of stream
>
>Simon Goldschmidt wrote
>> Michael Steinecke wrote:
>>> Sergio R. Caprile wrote
>>>>>>/ The FW Library bug in the Ethernet IRQ, eating fast packets is
>fixed./
>>>>>So no, this does not seem to be the standard STM issue...
>>>>
>>>> Oh, I see, missed that part. Should we believe the vendor ? (terrified
>>>> face)
>>> 
>>> I think there is another related bug as well. The semaphore to signal new
>>> packets is a binary one. It should be a counting one. I had it at least
>> 
>> Ehrm, wasn't that the STM bug we were talking about? At least I think I
>> remember something like that being discussed on this list...
>> 
>> So you haven't fixed it? That could explain retransmissions...
>
>No I'd fixed that one for the entire time. The post I'd read regarding the
>famous bug talked about
>http://lists.nongnu.org/archive/html/lwip-users/2014-03/msg00033.html 
>This is fixed in the meantime by STM32
>
>
>
>--
>View this message in context: 
>http://lwip.100.n7.nabble.com/TCP-retransmission-flooding-at-end-of-stream-tp23275p23313.html

>Sent from the lwip-users mailing list archive at Nabble.com.
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/lwip-users
>