topic Interniche Lite buffer problem in ColdFire/68K Microcontrollers and Processors

Interniche Lite buffer problem

JonEven — Tue, 19 Apr 2011 18:29:42 GMT

Hi,

Im using the Interniche Lite stack from 2006(?). It came with the MCF52235 EVB. I'm having problems with

what seems to be packet buffers not getting freed.

After system startup i have 9 bigbufs and 5 small bufs free. Every minute or so i print the number of free buffers.

After some time, let's say 30 mins of traffic on the ethernet, the number of free bigbuffer goes down to 8 or 7.

Some time later (lets say another 30 mins) it goes down by one or two buffers more. Ultimaltily, I have no big buffers left for packet transmission, which results in an udp_alloc error cant allocate a buffer for the packet to be sent. So, I'm thinking there must be a bug somewhere that causes this problem.

The system can run forever if the mcf52235 is simply receiving broadcasts (No need for PC server updating ARP table?).

But, when the system is running with packets directed directly to the uC IP address, the problem starts.

My theory is that when the top side computer must send directly to the board it needs to occationaly send an ARP request

to the board, and that this ARP sometimes causes a problem with the buffers/ buffer descriptors not getting freed.

Im not sure that it really is ARP related though. It may be something completely different, but I just wanted to know if anybody else has had similar problems?

Jon Even

Re: Interniche Lite buffer problem

TomE — Wed, 20 Apr 2011 12:05:11 GMT

I'd print the contents of the "leaked buffers" and then decode the contents of the contained network packet.

By seeing the addresses, protocol and type of the packet you should be able to work out what code generated or received the packet, and thereby spot the leak.

Tom

Re: Interniche Lite buffer problem

jonathanlawry — Tue, 20 Nov 2012 20:38:05 GMT

Jon,

We're seeing exactly the same thing! Are you still having a problem? We're using an MCF52236, with the Interniche stack from 2006 as well.

Through painstaking analysis, we discovered a big chunk of the problem. It seems that the buffers are "lost" on transmit: In fectx_internal(), transmit buffers are pulled off the FEX transmit queue (fectxq), and put into the "buffer descriptor array" called txpend[]:

pkt = (PACKET)getq(&fectxq); /* get pkt to send */

txpend[next_txbd] = pkt;

...while the status of the buffer descriptor itself is checked in the lines before (see line with MCF_FEC_TxBD_R), the spot in the txpend[] array isn't checked for NULL-ness. Changing the code to:

pkt = (PACKET)getq(&fectxq); /* get pkt to send */

if(txpend[next_txbd] == NULL) {

txpend[next_txbd] = pkt;

} else {

pk_free(pkt);

break;

}

...helped a great deal. This code change reduced the problem by about 90%. This, combined with a periodic test for lost buffers (and a reset if we get in an unrecoverable situation), got us out of the woods.

I would very much like to talk with you if you are still experiencing this.