Re: [ECOS] MPC860 Ethernet driver problem.

[Jonathan Larmour <jlarmour at redhat dot com>]

Gary Thomas wrote:
> 
> 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 :-).
> >>
> >> 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.

If it is stalled, it won't even get a TxEvent I'd have thought.

> 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.

You only need worry about the mbuf you're about to overwrite surely.
Scanning for those every time you send a packet and are stalled seems
wasteful.

But yes, the txbd->ctrl should probably be invalidated if overwriting an
existing one, just in case the whole thing does start up again (once that's
working).

>  Convincing
> the chip to actually start transmitting again when the carrier returns
> is probably another matter.

But is obviously a prerequisite to sensible behaviour anyway.

One would like to believe that the Quicc can indicate when the link
returns. I see in quicc_eth.h that the event register can have a
QUICC_SCCE_TXE event indicating a tx error. There's also a transmit buffer
status which includes QUICC_BD_TX_CSL to indicate carrier lost.

It would probably help if Geoff could find out what the state of the queued
up buffers actually is, whether we get a TXE interrupt, and what happens as
a result. Geoff, can you do this?

NB I don't really know anything about the Quicc so I'm reluctant to try
(and I'm pretty busy on tother things anyway)

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine