[Top][All Lists]
[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%6lu©j
> [mailto:address@hidden|k%6lu©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