Re: CAN messages being lost on i.MX25 with flexcan - continued (was CAN messages being lost on i.MX25 with flexcan - 2012-04-19)

[Wolfgang Grandegger <wg@grandegger.com>]

On 10/29/2013 01:40 PM, Martin Kozusky wrote:
> Dne 29.10.2013 13:03, Wolfgang Grandegger napsal(a):
>> On 10/29/2013 11:46 AM, Martin Kozusky wrote:
...
>>> Hello Wolfgang,
>>> it seems that my architecture (arm/mx25 on 2.6.35 kernel) is missing
>>> HAVE_FUNCTION_GRAPH_TRACER, HAVE_DYNAMIC_FTRACE options so it won't be
>>> that easy, will be?
>>> Timestamps that ftrace is showing me are in 10 miliseconds resolution,
>>> that won't help me much :(

Are high resolution timers enabled in the kernel? Still, event tracing
could would already be useful.

>> Probably that version is to old for proper ftrace support. The 100us you
>> measured for alloc_can_skb() is worst case, right? What is the mean
>> value?
> 
> Now I checked again and logged every call (don't know if realy
> everything was logged but something was :) and I see that it is not
> 100usec, but only around 20usec (mean value - checked by eye). There
> were some very long calls (around 2ms!) that were puttings errors in my 
> sum/count formula (may be I should filter out calls longer that
> 200usec), with this error it was not 100usec, but almost 1ms (my value
> was only 32bit and was overflowing when I wrote it first time). So
> normally around 20usec, but with very long calls around 2-3 ms (looks
> like those long are periodic - each 6th - 8th call is much longer, but
> not all the time)

Are these long latencies related to the SDcard accesses? I think the
problem is the rather long latencies caused by other kernel activity. In
your case caused by the MMC (SDcard) driver, I assume. The Flexcan
controller does buffer up to 5 messages before loosing packets.

> But still with those 20usec call, there are many RX overflows, if I
> disable the call alloc_can_skb, there are no overflows and all is
> received (but still not processed further, because I don't have skb ... )

Could you run this test for a longer time? The probability is just lower
that RX gets interrupted for a longer time, I think.

I see a few approaches to overcome this problem:

- fix the MMC driver to cause less latency. If you are lucky this is
  already the case in more recent versions of the kernel.

- Use the "-rt" extension (CONFIG_PREEPMT_RT). It will then allow to
  adjust priorities of soft and hard irq threads.

- Do the RX processing in the interrupt context, which would require
  some custom modifications.

Wolfgang.