linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andri Yngvason <andri.yngvason@marel.com>
To: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	Oliver Hartkopp <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org, wg@grandegger.com,
	hrafnkell.eiriksson@marel.com, haukur.hafsteinsson@marel.com
Subject: Re: peak_pci: TX Frame Loss
Date: Tue, 22 Dec 2015 11:51:08 +0000	[thread overview]
Message-ID: <20151222115108.GA9052@maxwell.marel.net> (raw)
In-Reply-To: <56790625.6060908@peak-system.com>

On Tue, Dec 22, 2015 at 09:13:25AM +0100, Stephane Grosjean wrote:
> Hi Andri,
> 
> We're currently investigating hard onto this issue. On my side, I'm checking
> the software part and I'd like to discuss with you about one point:
> 
> AFAIK the "sja1000_start_xmit()" function calls are really serialized by the
> network core. So there's actually no need of any lock to share the access of
> the SJA1000 registers, regarding the Tx path. Right. But I don't see in this
> function any test condition over the Transmit Status bit before writing the
> outgoing CAN frame (aka "reg[SJA1000_SR] & SR_TS").
>
I tried adding it and it didn't do anything. See original message.
> 
> Without testing the Transmit Status bit before writing, wouldn't it be
> possible that any 2nd task overwrite a 1st frame written by a 1st task
> before it has been really sent by the SJA1000?
> 
I don't think so. The _start_xmit() call is scheduled via the wait queue, so
_start_xmit() being called concurrently would be a sign of a misbehaving wait
queue, but like I said, adding the check did not yield any results.

Thanks & Merry Xmas!
Andri

  reply	other threads:[~2015-12-22 11:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 14:51 peak_pci: TX Frame Loss Andri Yngvason
2015-11-19  8:38 ` Stephane Grosjean
2015-11-19 10:12   ` Andri Yngvason
2015-12-02 18:09 ` Andri Yngvason
2015-12-02 19:19   ` Oliver Hartkopp
2015-12-03  6:37     ` Oliver Hartkopp
2015-12-03 11:23       ` Andri Yngvason
2015-12-03 11:44         ` Marc Kleine-Budde
2015-12-08 10:21           ` Stephane Grosjean
2015-12-08 10:50             ` Andri Yngvason
2015-12-08 11:42               ` Stephane Grosjean
2015-12-08 12:24                 ` Andri Yngvason
2015-12-08 14:12                   ` [BULK]Re: " Stephane Grosjean
2015-12-22  8:13                   ` Stephane Grosjean
2015-12-22 11:51                     ` Andri Yngvason [this message]
2015-12-03 16:37         ` Stephane Grosjean
2015-12-03  8:20     ` Marc Kleine-Budde

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=20151222115108.GA9052@maxwell.marel.net \
    --to=andri.yngvason@marel.com \
    --cc=haukur.hafsteinsson@marel.com \
    --cc=hrafnkell.eiriksson@marel.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=s.grosjean@peak-system.com \
    --cc=socketcan@hartkopp.net \
    --cc=wg@grandegger.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 NNTP newsgroup(s).