[Top][All Lists]

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

Re: [lwip-users] Delay fixes dropped packets

From: JM
Subject: Re: [lwip-users] Delay fixes dropped packets
Date: Sun, 9 Aug 2009 17:40:52 -0700 (PDT)

I think I may have figured out the problem.  As I suspected, it was something almost too obvious.  I commented out the lines that disable/enable global interrupts in sys_arch_protect() to solve an unrelated problem.  I tested the code afterward, and it still seemed to work.  Later it quit working due to some other unknown change.  I even reverted sys_arch_protect() back to normal, but it still didn't work, probably because of insufficient pbufs.  Enabling debugging must have added enough delay to mask it somehow.  I guess that's how learning something new goes....

--- On Sun, 8/9/09, address@hidden <address@hidden> wrote:

From: address@hidden <address@hidden>
Subject: Re: [lwip-users] Delay fixes dropped packets
To: "Mailing list for lwIP users" <address@hidden>
Date: Sunday, August 9, 2009, 4:17 AM

From your description, it seems like memory beloging to a packet is being changed after being delivered to your netif->linkoutput function. Does your MAC support DMA? If so, make sure the pbufs are freed after receiving a transmit interrupt for the packet. (pbuf_free(p) then must *not* be called directly in the linkoutput function! Doing so leads to memory being freed before it is actually transmitted. Thus the next call to pbuf_alloc will get the same pbuf and may alter the data while the MAC sends it using its DMA engine.


JM wrote:
> I'm using lwIP on a Stellaris micro, and saw lots of dropped packets.  Upon further investigation, it turns out these packets were failing TCP checksum.  I noticed that if I enabled debugging in the correct areas, and enough of it, the issue went away.  Long story short, after lots of trial and error I discovered that if I disable debugging and add a delay of 300us at the very end, before the return, in ip_output_if(), it fixes the problem.  If I decrease the delay, the problem starts appearing and becomes worse as I continue to decrease the delay.
> The driver for the onboard ethernet controller is from the Luminary driver library.  I don't imagine that a very high percentage of users here use the same chip I'm using, but generally speaking, any idea what I can look for; what would cause this?  I'm mainly recieving data.  It's streaming audio data so once I initiate it, the stack only has to ACK.
> ------------------------------------------------------------------------
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

lwip-users mailing list

reply via email to

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