lwip-users
[Top][All Lists]
Advanced

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

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


From: Andre Puschmann
Subject: [lwip-users] Re: curious large packets and transmit stuck
Date: Wed, 07 Feb 2007 20:45:31 +0100
User-agent: Thunderbird 1.5.0.4 (X11/20060619)

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





reply via email to

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