Thanks Jonathan for the detailed reply! I couldn't find anything online that explained what really is going on.
> Most likely packet loss, and your remote end (the sender) has not > retransmitted the missing packet yet. It could mean that your receive > window size is too large for the pbuf space you have available. In other > words, you are telling the remote end that it can send more data without > acknowledgement than you actually have room for. What is hard to determine is what number of pbufs is good? I don't want to be on the edge, but I don't want to allocate 100 or more that I need. > That sounds like a port or driver problem (or a bug I haven't > encountered). Or a PowerPC problem. There is some kind of problem using a DMA channel to copy memory from the TSEC BD pointer to data to my data buffer. I know it's hard to believe, but I don't have problems with a limited number of pbufs if I use a software copy, or if I use DMA and have about 100 extra pbufs. This is the reason for the processor freezing with limited pbufs, *not* the OOS list consuming pbufs. > > Should there be a #define and a test and for the amount of ooseq's to be > > allowed to be buffered? If not, what is a practical limit? > > Your receive window (TCP_WND in lwipopts.h). With 65535, that isn't easy to accommodate. Is that number divided by the MTU a reasonable estimate? If there are so many out of order sequences, I think I'll have bigger problems (like bandwidth). > Nothing special should be required by the driver. The bigger problem is > why it doesn't get to that point. One thing I didn't do (but wasn't the reason for the lockup) was to release the BD before returning NULL. I eventually would run out of BDs, but the processor wouldn't have hung - the DMA memory copying was the cause. Thanks again! Bill _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
