Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Stanislav Meduna]

On 07.03.2014 09:46, Marc Kleine-Budde wrote:

> Adding the linux-can mailinglist to Cc.

I am not subscribed so maybe that's why the original mail
did not get through - I did Cc: linux-can@xxxxxxxxxxxxxxx

> Your kernel is missing the patch:
> 
> e358784 can: flexcan: fix mx28 detection by rearanging OF match table
> 
> With this patch the CAN core properly detected as an mx28, so that bus
> errors stay disabled (unless you enable them). If you need bus errors to
> detect not connected CAN busses, you need another patchset berr_limit,
> which is not yet mainline. I can repost it here, if you need it.

Ah ok.

Thank you, this probably points me to the right direction - I'll try
to implement this behaviour in my kernel (unfortunately
I cannot move to more recent one at the moment).

On 07.03.2014 09:40, Wolfgang Grandegger wrote:

> Maybe there is something wrong with you platform code or DTS file. What
> kernel are you using and how is the DTS can node defined in your DTS file?

This is a the 3.4.77 kernel with the realtime patches and without
the device tree, so these settings are missing and the patch does
not apply.

On 07.03.2014 09:32, Matthias Klein wrote:

> I made a similar observation on an i.MX537 with the 3.12.12-rt19
> kernel: I see the same interrupt flooed when the bus is
> disconnected.
>
> What do you mean with "kills the machine"? I have a high interrupt
> load, but the machine is still responsive.

In my case the ssh connection became hung or updated once per several
seconds etc. In one case it was even necessary to ifconfig down/up
the ethernet interface (NAPI overload? - no idea). The exact behaviour
might be related to the realtime patches - we need guaranteed response
times and runaway interrupt processing hogging the CPU at the realtime
priority is a problem.

Many thanks
-- 
                                      Stano

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/