This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: MPC860 Ethernet driver problem.
- To: Gary Thomas <gthomas at cambridge dot redhat dot com>
- Subject: Re: [ECOS] MPC860 Ethernet driver problem.
- From: Jonathan Larmour <jlarmour at redhat dot com>
- Date: Tue, 01 May 2001 17:08:57 +0100
- Cc: Geoff Patch <grp at cea dot com dot au>,"ecos-discuss at sources dot redhat dot com" <ecos-discuss at sources dot redhat dot com>
- Organization: Red Hat UK Ltd.
- References: <XFMail.20010501092249.gthomas@cambridge.redhat.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