From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Jonathan Larmour Cc: Geoff Patch , "ecos-discuss@sources.redhat.com" Subject: Re: [ECOS] MPC860 Ethernet driver problem. Date: Tue, 01 May 2001 08:23:00 -0000 Message-id: References: <3AEED2E9.D4251481@redhat.com> X-SW-Source: 2001-05/msg00004.html On 01-May-2001 Jonathan Larmour wrote: > Gary Thomas wrote: >> > I've seen another problem I believe: if the ring buffer fills up it starts >> > overwriting old txbd's. But if it doesn't call the higher layer's txDone, >> > the mbuf won't ever be freed as far as I can tell. Perhaps it's even the >> > same problem and you're out of mbufs? Try adding a call to >> > quicc_eth_TxEvent after the "No free xmit buffers" printf in >> > quicc_eth_send(). I think :-). >> > >> > Gary, care to comment? >> >> More likely is that with no carrier, the "engine" won't send packets and >> needs to be kicked when the carrier is restored. If the packet is not >> consumed by the ethernet chip (engine), the driver will stop trying to >> send anything. > > Still I think this memory/mbuf leak is an issue. Should I do what I > proposed? I don't think it will have any effect. The message comes because there are no free transmit descriptors, i.e. all possible "pending" messages have data in them and the engine is not moving them out. The TxEvent() routine will skip over all of these because none of them has gone empty. The way to handle this would be to detect the condition, then scan the buffers and call the 'tx_done' callback for each (indicating an error, but that is unused at the moment) and then invalidate the buffer. Convincing the chip to actually start transmitting again when the carrier returns is probably another matter.