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
next parent 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