All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Smolorz <ssm@domain.hid>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] RT-Socket-CAN bus error handling (was CAN errors and real-time behaviour (IRQ raise forever and may lock system))
Date: Mon, 19 Mar 2007 09:50:26 +0100	[thread overview]
Message-ID: <E1HTDZN-0006rl-2g@domain.hid> (raw)
In-Reply-To: <E1HTD6v-0004qo-QI@mailer.emlix.com>

Sebastian Smolorz wrote:
> Hi Jan,
>
> Jan Kiszka wrote:
> > Wolfgang Grandegger wrote:
> > > you know, on the SJA1000 the bus error interrupt can result in high
> > > error interrupt rates and even hang the system on slow processors. Just
> > > unplugging the CAN cable can cause such interrupt flooding. This
> > > problem
> > >
> > > popped up again recently and Sebastian proposed:
> > >> Last summer we had a discussion about the BEI issue on the
> > >> socketcan-ML. Two additional handling policies popped up:
> > >> 1. The interface could restart itself after an amount of BEIs, thus
> > >>    taking responsibility from the user application.
> > >> 2. The BEI could be completely disabled if no one is interested in
> > >>    this ype of error frame.
> > >
> > > As 2. is also my preferred solution, I have implemented it. The only
> > > downside is that you do not see the error counter increasing when
> > > /proc/rtcan/devices is inspected. We also discussed 1., but
> > > RT-Socket-CAN does not restart the CAN controller by purpose and just
> > > stoppping it requires user intervention.
> >
> > And if there is someone listening, how is the flooding issue on cable
> > unplug etc. solved by option 2?
>
> Hm, maybe we could implement 1 additionally (but without automatical
> restart)?

A more precise suggestion: What about letting BEIs appear until passive mode 
is reached and if the TX error counter doesn't count up any more (indication 
of start-up situation discovered by the SJA1000) the driver ceases to read 
out ECC any further (thanks Stephane for the hint). The controller would be 
still operating but not reporting BEIs any more. There has to be some 
mechanism to let BEIs through after the situation has normalized. Maybe the 
driver could check inside the interrupt handler if active mode was reached 
again after the above situation occured.

-- 
Sebastian


  reply	other threads:[~2007-03-19  8:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-03 14:09 [Xenomai-help] CAN errors and real-time behaviour roland Tollenaar
2007-03-05  8:49 ` Stéphane ANCELOT
2007-03-05  9:26   ` Roland Tollenaar
2007-03-05 10:39   ` [Xenomai-help] CAN errors and real-time behaviour (IRQ raise forever and may lock system) Stéphane ANCELOT
2007-03-05 11:26     ` Sebastian Smolorz
2007-03-05 11:42       ` Roland Tollenaar
2007-03-05 12:01         ` Sebastian Smolorz
2007-03-05 12:16           ` Roland Tollenaar
2007-03-05 12:48             ` Sebastian Smolorz
2007-03-05 13:13               ` Roland Tollenaar
2007-03-05 14:57       ` Stéphane ANCELOT
2007-03-05 14:42         ` Sebastian Smolorz
2007-03-05 17:02           ` Stéphane ANCELOT
2007-03-06  9:36             ` Sebastian Smolorz
2007-03-10 20:53               ` Wolfgang Grandegger
2007-03-14 11:38               ` [Xenomai-help] RT-Socket-CAN bus error handling (was CAN errors and real-time behaviour (IRQ raise forever and may lock system)) Wolfgang Grandegger
2007-03-14 12:51                 ` Sebastian Smolorz
2007-03-14 13:18                   ` Wolfgang Grandegger
2007-03-14 13:24                     ` Sebastian Smolorz
2007-03-17 11:56                   ` Wolfgang Grandegger
2007-03-18 10:22                     ` Jan Kiszka
2007-03-18 11:33                       ` Wolfgang Grandegger
2007-03-18 20:59                         ` Jan Kiszka
2007-03-19  8:21                           ` Sebastian Smolorz
2007-03-19  8:50                             ` Sebastian Smolorz [this message]
2007-03-19 11:35                               ` Wolfgang Grandegger
2007-03-19 11:46                                 ` Sebastian Smolorz
2007-03-19 13:05                                 ` Jan Kiszka
2007-03-19 20:44                                   ` Wolfgang Grandegger
2007-03-19 21:19                                     ` Wolfgang Grandegger
2007-03-19 22:25                                       ` Jan Kiszka
2007-03-20  6:53                                         ` Wolfgang Grandegger
2007-03-19  8:54                             ` Wolfgang Grandegger
2007-03-19 16:48                             ` Stéphane ANCELOT
2007-03-19 16:56                               ` Sebastian Smolorz
2007-03-19 17:33                                 ` Jan Kiszka
2007-03-19  8:49                     ` Stéphane ANCELOT
2007-03-19  8:30                       ` 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=E1HTDZN-0006rl-2g@domain.hid \
    --to=ssm@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.