All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>, linux-can@vger.kernel.org
Subject: Re: flexcan driver: tx_bytes counter never incremented when CAN_RAW_LOOPBACK removed?
Date: Tue, 30 Apr 2013 13:37:27 +0200	[thread overview]
Message-ID: <517FACF7.8050000@grandegger.com> (raw)
In-Reply-To: <517F9A94.8080308@grandegger.com>

On 04/30/2013 12:19 PM, Wolfgang Grandegger wrote:
> On 04/30/2013 08:47 AM, Stephane Grosjean wrote:
>> Le 29/04/2013 14:55, Wolfgang Grandegger a écrit :
>>>> I also have seen that the flexcan ctrlr (iMx25) behaves oddly when rx
>>>> overrun occurs: each time I get such an OVR INT., I also get some
>>> OVR INT? What error do you mean?
>>
>>         /* FIFO overflow */
>>         if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
> 
> OK... and there is no good reason for a FIFO overflow, right? I mean the
> reception rate is not really high.
> 
>>>> spurious TX INT. too, while I never sent anything on the CAN. So, for
>>>> me, handling tx_bytes/tx_packets stats when sending the data would fix
>>>> everything!
>>> See above. What has the handling of tx_bytes/tx_packets stats to do with
>>> spurious TX INT or the OVR INT?
>>
>>         /* transmission complete interrupt */
>>         if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
>>                 stats->tx_bytes += can_get_echo_skb(dev, 0);
>>                 stats->tx_packets++;
>>
>>
>> I don't even know the reason for the moment but when any
>> RX_FIFO_OVERFLOW interrupts occur, some (spurious) TX_BUF_ID follow too
>> (to be more precise: FLEXCAN_TX_BUF_ID bit is sometimes set too in
>> iflag1), which leads "tx_packets" to increase while no CAN frames have
>> been sent at all! Didn't find any documentation nor errata about this,
>> but it's a fact.
> 
> Hm, looks like a bug on this FLexcan variant, which is a very early one,
> I think. Could you please printk "reg_iflag1",  "reg_iflag2" and
> "reg_esr" at the beginning of "flexcan_irq" and show us the dmesg output
> when such an error shows up?
> 
>> My proposal was only a quick 'n secure workaround for both issues:
>> "tx_bytes always 0 when LOOPBACK not set" AND "wrong tx_packets (and
>> tx_bytes) management on spurious TX INTerrupts".
> 
> Well, still two separate issues which needs to be addressed separately.

In 2012 a similar issue has been discussed on this list with the subjects:

 "CAN messages being lost on i.MX25 with flexcan"
 "can4linux compilation for i.mx25 under 2.6.39"

Eventually the interrupts on your system are also block for too long
resulting in FIFO overflows. Do you realize message losses?

Wolfgang.

  reply	other threads:[~2013-04-30 11:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 14:50 Patch for kvaser_usb Jonas Peterson
2013-04-26 15:00 ` Marc Kleine-Budde
2013-04-26 16:35   ` Jonas Peterson
2013-04-26 20:51     ` Olivier Sobrie
2013-04-29  7:53       ` Marc Kleine-Budde
2013-04-29 10:40         ` flexcan driver: tx_bytes counter never incremented when CAN_RAW_LOOPBACK removed? Stephane Grosjean
2013-04-29 10:53           ` Marc Kleine-Budde
2013-04-29 12:37             ` Stephane Grosjean
2013-04-29 12:44               ` Marc Kleine-Budde
2013-04-29 12:55               ` Wolfgang Grandegger
2013-04-30  6:47                 ` Stephane Grosjean
2013-04-30 10:19                   ` Wolfgang Grandegger
2013-04-30 11:37                     ` Wolfgang Grandegger [this message]
2013-04-29 13:43             ` Kurt Van Dijck
2013-04-29  7:52     ` Patch for kvaser_usb Marc Kleine-Budde
2013-04-29 11:09   ` Jonas Peterson
2013-04-30 21:40   ` [PATCH] can: kvaser_usb: handle rx msg correctly Olivier Sobrie
2013-05-02 10:35     ` Marc Kleine-Budde
2013-05-02 18:06       ` Olivier Sobrie
2013-05-02 18:57         ` [PATCH v2] " Olivier Sobrie
2013-05-03  9:51           ` Marc Kleine-Budde
2013-05-07 20:05             ` [PATCH v3] " Olivier Sobrie
2013-05-15 10:05               ` Marc Kleine-Budde
2013-05-15 11:50                 ` Olivier Sobrie
2013-05-03  9:49         ` [PATCH] " Marc Kleine-Budde
2013-05-06 20:00           ` Olivier Sobrie

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=517FACF7.8050000@grandegger.com \
    --to=wg@grandegger.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=s.grosjean@peak-system.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.