[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-can
Subject:    Re: flexcan driver: tx_bytes counter never incremented when CAN_RAW_LOOPBACK removed?
From:       Wolfgang Grandegger <wg () grandegger ! com>
Date:       2013-04-30 11:37:27
Message-ID: 517FACF7.8050000 () grandegger ! com
[Download RAW message or body]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]