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

Wolfgang Grandegger wrote:
>>> The problem is to define what degree of error-related IRQ load is
>>> generally acceptable. We surely can't do this, so we have to document
>>> the effect /at least/ and help the users to check it on their own - or
>>> we have to avoid it / make it insignificant compared to normal CAN
>>> operation (I'm still in favour of this path).
>>
>> We speak about a pathological situation and therefore I do not share
>> your concerns. When there are electrical problems or even the cable is
>> not connected, we do have an abnormal mode of operation and CAN
>> related real-time is broken anyhow. The bus error messages are then
>> useful for analyzing the problem. The effect of the bus error

I do understand, and that's why I was looking for some solution that
rate-controls such IRQs deterministically, but doesn't switch them off
altogether.

>> interrupts on non-CAN related latencies is another issue but I think
>> it's not that critical either (handling a bus error just requires the
>> reading of 2 SJA1000 registers). But I agree, a more detailed analysis
>> of "bus error flooding" would help to understand the impact on the
>> real-time behavior.
> 
> And also be aware, that heavy CAN traffic can cause similar latencies as
> well and when there is more than one CAN controller, they can accumulate
> (as I have observed with my PCAN dongle tests). Here a IRQ service task

Well, this argumentation doesn't help if some concrete CAN bus was
specified to _not_ deliver such high traffic.

> or threaded IRQs would help. Maybe this is the right way to go.

Again: threaded IRQs are no magic bullet. First of all, they add
latencies, specifically on low-end. And they can only help if IRQ
priorities can actually be lowered appropriately (or if you apply
round-robin or a similar CPU bandwidth policy).

Jan


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