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: 1592 bytes --]

Sebastian Smolorz wrote:
> Stéphane ANCELOT wrote:
>>> IIRC, there is no possibility to detect a "normal" bus error
>>> (acknowledge) appearing during normal operation from the one occuring
>>> when the cable is plugged off. The best indication is a high number of
>>> consecutive BEIs.
>> I do not agree :
>> case normal :
>> In normal bus error condition, if error repeats the chip will go to
>> busoff state (unfortunately I don't know how to simulate this...)
>>
>> case unplugged (easy to simulate):
>> when the cable is not plugged it will not go to busoff condition.
> 
> I know that. Unfortunately, you took my above answer out of context. I replied 
> to:
> 
>> 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?
> 
> I was referring to *one* bus error. If one bus error occurs how will the 
> driver know it is the beginning of a flood due to an unplugged cable? It can 
> only tell after serveral consecutive ones.

As damn SJA1000 doesn't seem to help us here, I was suggesting to play
safe: disable that particular IRQ source until administrator reset or
some task reads the generated error frame AND (that's probably required
too) continues to ask for the next one.

The latter condition would allow the error frame reader to fully control
the IRQ rate. Note that this is not just about avoiding total lock-up.
Even a specific period of an abnormal IRQ load can kill an RT system.

Jan


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