Linux CAN drivers development
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Amr Bekhit <amrbekhit@gmail.com>
Cc: wg@grandegger.com, mkl@pengutronix.de, linux-can@vger.kernel.org
Subject: Re: Flooding AT91_CAN peripheral with messages causes it to stop receiving any more messages
Date: Mon, 02 May 2016 08:23:58 +0200	[thread overview]
Message-ID: <1834894.mYn6oCiL2x@ws-stein> (raw)
In-Reply-To: <CAOLz05quWjxFaxdPcLvybc4YdTmE+qUGhbKUCjji6DGNAUwZ3g@mail.gmail.com>

On Tuesday 05 April 2016 14:10:48, Amr Bekhit wrote:
> I working on a board based on the AT91SAM9X25 SoC and I'm using
> integrated CAN peripheral. I seem to have run into an issue whereby
> sending lots of messages very rapidly in quick succession causes the
> CAN peripheral to then stop receiving any messages at all. The only
> way to bring it back to a functional state is to bring the network
> interface down and then back up again.
> [...]
> I then start sending CAN messages to the unit using a PCAN-USB adapter
> that is plugged into a test Linux PC. After bringing up the CAN
> interface on the test PC, messages can be continuously sent using the
> following bash script:
> [...]
> I then leave the system running for some time (1.5 hours typically,
> may vary), periodically running ifconfig can0 to check to see if new
> packets are being received. After a while, the can interface will stop
> receiving new packets, even though the test PC is still transmitting
> them. Stopping and restarting the CAN transmissions on the test PC
> does not solve the problem. The interface does not appear to be in the
> bus off state, as shown by running the following:

That sounds a bit like my getting stuck problem in http://linux-can.vger.kernel.narkive.com/bBQqK84G/resend-patch-net-can-at91-can-c-decrease-likelyhood-of-rx-overruns#post2

The patch post1 at least keeps the driver working. Although I don't know what 
has changed in at91_can meanwhile.

Best regards,
Alexander


  parent reply	other threads:[~2016-05-02  6:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 13:10 Flooding AT91_CAN peripheral with messages causes it to stop receiving any more messages Amr Bekhit
2016-04-08  7:39 ` Wolfgang Grandegger
2016-04-29  8:04   ` Amr Bekhit
     [not found]     ` <CAOLz05oo=EGqvmCaXXBhXs5McMmJDPKCzuiij7Pv22fj5hPB_g@mail.gmail.com>
2016-04-29  8:15       ` Amr Bekhit
2016-04-29 11:18     ` Wolfgang Grandegger
2016-04-29 11:29       ` Amr Bekhit
2016-04-29 14:27         ` Wolfgang Grandegger
2016-04-30 13:34         ` Wolfgang Grandegger
2016-05-02  6:23 ` Alexander Stein [this message]
2016-05-02 13:53   ` Wolfgang Grandegger
2016-05-03  8:27     ` Amr Bekhit
2016-06-01 13:21       ` Amr Bekhit
2016-06-03  7:22         ` Wolfgang Grandegger
2016-06-08  8:17           ` Amr Bekhit
2016-06-08  8:37             ` Wolfgang Grandegger
2016-06-10 13:34               ` Amr Bekhit

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=1834894.mYn6oCiL2x@ws-stein \
    --to=alexander.stein@systec-electronic.com \
    --cc=amrbekhit@gmail.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --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