[lwip-users] Re: curious large packets and transmit stuck

[Andre Puschmann]

Hey Guys,
we did some more research.
now i looks like we had a couple of smaller problems which all came
together and than turned into the described behavior.
just to let you know, eventually its useful for someone else.
we had problems in our fec-driver which formerly just handled one packet
in one interrupt call but ignored the case if there was more than one
available.
another thing were competing data structure accesses which were not
properly handled (i.e. lock interrupts).


Cheers,

André


Taranowski, Thomas (SWCOE) wrote:
> My hunch is that the driver is operating correctly, however, there is a point 
> at which it is unable to keep up with rate at which the stack is sending 
> buffers for transmit.  Something easy to try would be to double the number of 
> transmit/receive buffers used by the driver, and see if it has any effect on 
> the problem.  It could be possible that the driver is combining multiple 
> sends into a single interrupt, or it could be that the driver is just tossing 
> all sends which overflow transmit queue. You'd only be able to discover which 
> it is by driver source analysis or instrumentation.
> 
>> -----Original Message-----
>> From: address@hidden
>> [mailto:address@hidden On
>> Behalf Of Andre Puschmann
>> Sent: Wednesday, February 07, 2007 11:46 AM
>> To: address@hidden
>> Subject: [lwip-users] Re: curious large packets and transmit stuck
>>
>> hey thomas,
>> we are using a freescale mpc5200 and its integrated fec.
>> the os is a osek/vdx compliant one.
>> the driver uses the bestcomm dma engine that is integrated in the mpc5200.
>> i don't think that there is a problem at the basic functionality of the
>> driver but indeed there is a point which i can't understand.
>> if i count the times the fec_send()-method was called and the number of
>> fec-tx-interrupts they differ from time to time, i mean i got less
>> tx-interrupts, what properly shouldn't be the case.
>> if i really loose some tx-interrupts maybe i loose rx-interrupts as well?!
>> but how could that be?
>>
>>
>> Regards,
>>
>> Andre
>>
>>
>>
>> Taranowski, Thomas (SWCOE) wrote:
>>> I didn't see any details on what driver/hardware/os you're using, so I'm
>>> making an educated guess...
>>>
>>> The problem you describe could potentially be a problem within the
>>> driver.  I could see a scenario where the driver fails to send/transmit
>>> any data because, say, there are no transmit buffers available.  In this
>>> case the driver would fail to send, but be unable to notify that data
>>> was sent, depending on the implementation of the low level driver/stack
>>> interface.  In this case, the stack could be caught in some undefined
>>> state.  The receipt of the ping triggers a transmit, and an interrupt,
>>> and perhaps some other events, depending on the implementation, that
>>> could cause operation to resume, but you'd probably see that some
>>> packets were lost.
>>>
>>> I'd make sure that the driver send call never returns an error
>>> condition.  As a simple test, try increasing the size of the transmit
>>> queue, or whatever you use, for the driver.
>>>
>>> You could also increase the size of the PBUF_POOL_BUFSIZE option, so
>>> that the depth of the buffer chain sent to the driver is shorter.  This
>>> could result in fewer transmit buffers being used, depending on your
>>> implementation of course.
>>>
>>> -Thomas
>>>
>>> -----Original Message-----
>>> From: address@hidden|k%6l†uœ©j
>>> [mailto:address@hidden|k%6l†uœ©j]
>>> On Behalf Of Andre Puschmann
>>> Sent: Sunday, February 04, 2007 12:06 PM
>>> To: address@hidden
>>> Subject: [lwip-users] Re: curious large packets and transmit stuck
>>>
>>> hey guys,
>>> another thing that maybe brings a bit more light is the following. once
>>> the stack is as slow i can burst the things up for another ~300 packets
>>> with a single ping.
>>> after that burst transmission is slow again. but i can do this "trick"
>>> again and again.
>>> i already checked the timer function but they are called frequently.
>>> what can a single ping packet activate in the stack (or its helper
>>> functions)??
>>> any hints??
>>>
>>>
>>> best regards,
>>>
>>> andre
>>>
>>>
>>> Andre Puschmann wrote:
>>>> hi kieran,
>>>> here are my lwip opts.h and one trace using the netconn-api and
>>> another
>>>> one using the raw api ..
>>>> if you have a look at the first trace (netconn) you can see that the
>>>> packets slowly dropping out/in .. it seems that lwip "forgets" acks
>>> the
>>>> other end send. you can't see the large packets directly, i mean there
>>>> is one large and another small one, but before the stuck all packets
>>>> were 1000bytes long. so it seems that it has something to do with
>>> that.
>>>> if i use the raw api there are no "large" packets .. since as long as
>>>> lwip has something to send it sends packet with max size (1456byte).
>>> but
>>>> nevertheless, after a while the whole system shows the same behavior.
>>>>
>>>> do you think it has something to do with my timer/semaphore/mbox
>>>> implementation?
>>>>
>>>>
>>>> many thanks
>>>>
>>>> andre
>>>>
>>>>
>>>>
>>>> 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap
>>>> 2: http://www.puschmann.net/public/large_and_small_packet.cap
>>>> 3: http://www.puschmann.net/public/opt.h
>>>>
>>>>
>>>> Kieran Mansley wrote:
>>>>> On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote:
>>>>>> i am aware of this fact. the curious thing IMO is the correlation
>>>>>> between the occurrences of this "larger packets" and the stuck of
>>> the
>>>>>> whole stack.
>>>>> Sounds like you may either have a locking problem (the usual cause of
>>>>> deadlock) or possibly a resource allocation issue.  Is lwIP sending
>>> or
>>>>> receiving the large packet?  Could you get a packet trace using
>>>>> something like ethereal?  Your lwipopts.h configuration might throw
>>> some
>>>>> light on the problem too.
>>>>>
>>>>> Kieran
>>>
>>>
>>> _______________________________________________
>>> lwip-users mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users