Netdev List
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Bernie Innocenti <bernie@codewiz.org>
Cc: Ward Vandewege <ward@gnu.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Jan Seiffert <kaffeemonster@googlemail.com>,
	netdev@vger.kernel.org
Subject: Re: pc300too on a modern kernel?
Date: Mon, 22 Nov 2010 22:20:02 +0100	[thread overview]
Message-ID: <m38w0l2gzh.fsf@intrepid.localdomain> (raw)
In-Reply-To: <1290442675.5515.92.camel@giskard.codewiz.org> (Bernie Innocenti's message of "Mon, 22 Nov 2010 11:17:55 -0500")

(added Cc: netdev)

Bernie Innocenti <bernie@codewiz.org> writes:

> Now the question is: why do we get so many spurious interrupts?

Let me see... we call sca_tx_done() on (isr0 & 0x2020) which are DMIB3
and DMIB1, which in turn are (EOT & (EOTE = 0) | EOM & (EOME = 1)), i.e.
the interrupt is generated on EOM (end of message = packet).

It seems TN-PSC-339A/E is the answer: the interrupt is generated at the
end of the last DMA access filling the TX buffer. Only then the status
is written to the descriptor (=RAM). I guess it didn't make a difference
on older, slower machines, with slower paths from PCI to CPU.
Also I don't know if the descriptor status is being written in the same
DMA transfer (between the chip and on-board SRAM) as the last data
transfer. Perhaps it's another DMA request and arbitration, and perhaps
the chip has to wait for another transfer to finish.

> With this workaround applied, we're st seeing occasional clusters of
> packet loss. We're working to graph the ping loss alongside traffic to
> see if there's any correlation.

That's interesting. I remember seeing some TX underruns at higher
speeds, though nothing alike at 2 Mb/s. What bit rate are you using?
Does "ifconfig hdlc0" show any errors?
-- 
Krzysztof Halasa

       reply	other threads:[~2010-11-22 21:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100902131531.GA19028@countzero.vandewege.net>
     [not found] ` <m3mxrw1lg0.fsf@intrepid.localdomain>
     [not found]   ` <1289421869.9336.49.camel@giskard.codewiz.org>
     [not found]     ` <m3sjz34mka.fsf@intrepid.localdomain>
     [not found]       ` <1289944619.2677.22.camel@giskard.codewiz.org>
     [not found]         ` <m3tyjd7za9.fsf@intrepid.localdomain>
     [not found]           ` <1290442675.5515.92.camel@giskard.codewiz.org>
2010-11-22 21:20             ` Krzysztof Halasa [this message]
2010-11-23 14:44               ` pc300too on a modern kernel? Ward Vandewege

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=m38w0l2gzh.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --cc=bernie@codewiz.org \
    --cc=kaffeemonster@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ward@gnu.org \
    /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