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

[Wolfgang Grandegger <wg@domain.hid>]

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

Wolfgang.