public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gthomas@cambridge.redhat.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Cc: Geoff Patch <grp@cea.com.au>,
	"ecos-discuss@sources.redhat.com"
	<ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] MPC860 Ethernet driver problem.
Date: Tue, 01 May 2001 08:23:00 -0000	[thread overview]
Message-ID: <XFMail.20010501092249.gthomas@cambridge.redhat.com> (raw)
In-Reply-To: <3AEED2E9.D4251481@redhat.com>

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.

  reply	other threads:[~2001-05-01  8:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01  0:20 Geoff Patch
2001-05-01  5:48 ` Jonathan Larmour
2001-05-01  8:03   ` Gary Thomas
2001-05-01  8:15     ` Jonathan Larmour
2001-05-01  8:23       ` Gary Thomas [this message]
2001-05-01  9:09         ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=XFMail.20010501092249.gthomas@cambridge.redhat.com \
    --to=gthomas@cambridge.redhat.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grp@cea.com.au \
    --cc=jlarmour@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).