Re: [Xenomai-help] RT-Socket-CAN bus error handling (was CAN errors and real-time behaviour (IRQ raise forever and may lock system))

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Back to our preferred solution 1. Attached is a patch for review
>>> including some other fixes and suggestions accumulated over time:
>>>
>>>      * ksrc/drivers/can/*: To avoid unnecessary bus error interrupt
>>>      flooding, the option CONFIG_XENO_DRIVERS_CAN_BUS_ERR now allows to
>>>      enable bus error interrupts "on demand" only if an application is
>>>      interested in such errors. It is automatically selected for CAN
>>>      controllers supporting bus error interrupts like the SJA1000.
>>
>> Jumping into this more or less blindly: Could you explain to me (as well
>> as the poor CAN users...) what the downsides of enabling
>> CONFIG_XENO_DRIVERS_CAN_BUS_ERR are? If there isn't anything
>> significant, I would strongly vote for keeping the switch forest as
>> small as possible.
> 
> The user has not to care and cannot even enable this option. It is auto
> selected for SJA1000. The purpose of this config option is to suppress
> correlated code for builds without SJA1000. About the functionality: as

Hmm, probably the attached help text confused me (who should see it BTW?).

> 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?

What about something like option 3: After the first error occurred that
may mark the beginning of a flood, disable that error interrupt until
the next stop/start cycle or the user has read the event?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]