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/30/2013 10:14 AM, "Martin Kožuský [KK micro s.r.o.]" wrote:
> -------- Original Message  --------
> Subject: Re: CAN messages being lost on i.MX25 with flexcan - continued
> (was CAN messages being lost on i.MX25 with flexcan - 2012-04-19)
> From: Wolfgang Grandegger
> To: Martin Kožuský [KK micro s.r.o.], linux-can@vger.kernel.org
> Date: 30. Říjen 2013 10:04:13
> 
>> On 10/30/2013 09:43 AM, "Martin Kožuský [KK micro s.r.o.]" wrote:
>>> -------- Original Message  --------
>>> Subject: Re: CAN messages being lost on i.MX25 with flexcan - continued
>>> (was CAN messages being lost on i.MX25 with flexcan - 2012-04-19)
>>> From: Wolfgang Grandegger
>>> To: Martin Kozusky, linux-can@vger.kernel.org
>>> Date: 29. Říjen 2013 15:30:08
>>>
>>>> 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.
>>> I think it is not primary related to SD card, those tests I was doing
>>> lately were done when system was idle, no special processes were
>>> running. But when I do access SD card, problems get bigger.
>>>
>>>>> 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 have run it for a few minutes, problem is still the same :(

BTW: with long I was thinking about hours rather than minutes.

>>>
>>>> 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.
>>> Hard to say if this helps when it's also doing in idle.
>>
>> OK, then I misinterpreted your error description.
>>
>>>> - Use the "-rt" extension (CONFIG_PREEPMT_RT). It will then allow to
>>>>     adjust priorities of soft and hard irq threads.
>>> I don't know if there is a patch for this :(
>>>
>>>> - Do the RX processing in the interrupt context, which would require
>>>>     some custom modifications.
>>> I was thinking about writing data directly to fifo file, my program
>>> would read from it
>>
>> Well, before hacking something you should try to find out what is
>> provoking the long latencies (> 1ms). FTrace is your friend. Therefore I
>> would try to get a more recent version of the kernel running somehow.
>> 2.6.39 should already be much better.
> I will try to get new kernel running, but when I checked the patch for
> 2.6.35, I see some incompatibilites in directory structure and files, so
> I will have to go line-by-line and make my patch that will fit the new
> kernel. And when I do that, I will try it on latest 3.x kernel. I hope I
> will make it work.

Porting board support to a recent kernel version would be ideal, of
course. But it might be much less straight-forward than porting to a
close version, e.g. 2.6.39. Note that version 2.6.35 is more 3 years old.

Wolfgang.