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

Sebastian Smolorz wrote:
> Stéphane ANCELOT wrote:
>> Sebastian Smolorz wrote:
>>> Stéphane ANCELOT wrote:
>>>> Sebastian Smolorz wrote:
>>>>> Note that the current implementation of RT-Socket-CAN shows this
>>>>> behaviour on purpose. See also [1] ("may flood!"). Whether this is the
>>>>> right handling or not may be discussed here. I admit that the current
>>>>> implementation forces an application developer to take more
>>>>> responsibility but that is not a bug of the underlying driver/stack per
>>>>> se. Look, you don't connect anything to the CAN bus, start a
>>>>> *real-time* application which sends a message to a non-existent CAN
>>>>> node. This is an error situation an it is more than ever for a
>>>>> real-time task. So the proper reaction for a RT-application would be to
>>>>> handle those errors and e.g. shut down the CAN interface which in this
>>>>> case will force the CAN hardware to stop its endless attempts to send
>>>>> the message.
>>>> I agree and this is what I was doing , however this does not seem to
>>>> work as expected in the driver.
>>> What does not work? The shutdown and stopping transmitting the CAN
>>> messages?
>>>
>>> --
>>> Sebastian
>> Yes, this is exactly what has happened to me and rolland problem , one
>> rtcansend launched and BEI interrupt come always....
> 
> Yes, I know. But when you stop the CAN interface in such a situation the 
> interrupts must disappear because the controller does not try to send the 
> message any more.
> 
>> since the error management shoudl be done by appplication process, I
>> think that BUS ERROR INTERRUPT can be reported however the ECC reading
>> must not be done by the interrupt routine.
> 
> I don't think that reading the ECC is the critical point, rather the interrupt 
> flodding is.
> 
>> Since it permits  a next bus error interrupt. the ECC reading should be
>> left to user application eg through an ioctl.
> 
> Error reporting in RT-Socket-CAN is the same as in Socket-CAN for plain Linux.
> It is done via error frames sent to the application. So  your suggestion would 
> break the API here and frankly is not necessary. You have several 
> possibilities to detect a bus error due to a disconnected bus and can handle 
> the situation properly (e.g. restart the interface). If a series of error 
> frames are generated which shows you TX bus errors with missing 
> acknowledgments you can be quite sure that no other node is connected to the 
> bus.
> 
>> This  may be an option or a error mode selectable by the programmer at
>> startup .
>>
>> what do you think ?
> 
> 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 type 
> of error frame.

I tried to implement 2. for SJA1000, but re-enabling the BIE on the fly
does not work. :-(. The controller requires a re-start of the device to
get the bus error reporting back to work.

> Maybe it is time to think about the implementation of these policies as more 
> and more users seem to run into the BEI issue with a disconnected bus. 
> Wolfgang, Jan, what is your opinion?

Well, solution 2. with the limitations mentioned above is therefore less
attractive because it interrupts the CAN traffic. The Socket-CAN 
implementation actually restarts the CAN controller after a certain 
amount of bus error interrupts (200 by default) which matches your first 
policy above. But in RT-Socket-CAN, we do not automatically re-start the 
device by purpose. Therefore I tend to just stop the device. It's then 
up to the application to restart it. What do you think?

Wolfgang.