Re: [Xenomai-help] 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 personally prefer 2. More below...

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

Just trying to catch up with this issue. As you mention, it has already 
been discussed on the Socket-CAN mailing list. Just follow 
https://lists.berlios.de/pipermail/socketcan-core/2006-July/000215.html.
I realized as well, that it is easily possible, to flood the system with 
BIE interrupts, especially on low end systems. The problem gets worse, 
when the error frames are delivered to the socket or even printk debug 
messages are generated due to buffer overflows. The latter can be 
suppressed by disabling RTCAN debugging (via XENO_DRIVERS_CAN_DEBUG). 
Then the system normally will _not_ hang because the interrupt rate is 
not critical. Nevertheless, this issue should be re-discussed on the 
Socket-CAN mailing list. I will not accept a rt-only only solution.

Wolfgang.