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: [EMAIL PROTECTED]|k %6l u©j > [mailto:[EMAIL PROTECTED]|k %6l u©j] > On Behalf Of Andre Puschmann > Sent: Sunday, February 04, 2007 12:06 PM > To: [email protected] > 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
