From: Stanislav Meduna <stano@meduna.org>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
wg@grandegger.com, linux-can@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: FlexCAN on i.MX28 interrupt flooding retrying send
Date: Fri, 07 Mar 2014 14:36:24 +0100 [thread overview]
Message-ID: <5319CB58.4070708@meduna.org> (raw)
In-Reply-To: <53198753.8000900@pengutronix.de>
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@vger.kernel.org
> 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
next prev parent reply other threads:[~2014-03-07 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 8:08 FlexCAN on i.MX28 interrupt flooding retrying send Stanislav Meduna
2014-03-07 8:16 ` Marc Kleine-Budde
2014-03-07 8:40 ` Wolfgang Grandegger
[not found] ` <OF203965D8.128520F3-ON86257C94.004FA84A-86257C94.0050AF36@notes.cat.com>
2014-03-07 15:36 ` Wolfgang Grandegger
2014-03-07 8:32 ` Matthias Klein
2014-03-07 8:46 ` Marc Kleine-Budde
2014-03-07 13:36 ` Stanislav Meduna [this message]
2014-03-07 13:54 ` Marc Kleine-Budde
[not found] ` <OFA84C0F6D.092C777B-ON86257C94.004E3F0B-86257C94.004F1F2D@notes.cat.com>
2014-03-07 14:40 ` Marc Kleine-Budde
2014-03-07 15:55 ` Wolfgang Grandegger
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=5319CB58.4070708@meduna.org \
--to=stano@meduna.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=wg@grandegger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).