On Wed, Feb 03, 2010 at 08:34:50AM +0100, Wolfgang Grandegger wrote:
> Hello,
>
> as Marc mentioned in another thread, our current bus-error handling is
> weak. It does make trouble frequently, especially on low-end systems.
> How could we improve our current bus-error handling? I proposed a quite
> simple solution allowing the user to switch off bus-error generation using:
>
> ./ip link set can0 up type can bitrate 500000 bus-errors 0
>
> This is usually easy to implement by just not enabling the bus-error
> interrupt of the CAN controller. Marc proposed:
>
> > A possible solution might be to switch of the error interrupt and poll
> > it e.g. with delayed work.
>
> Detecting a high rate and throttling the rate is not trivial and I
> hesitate to add a complex solution, also because bus-errors are only
> available on a few CAN controllers, e.g. SJA1000 and AT91. Marc, what do
> you have in mind?
>
> In RT-Socket-CAN, bus-errors are only delivered on demand. See:
>
> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/Kconfig#052
I haven't any RT-socket-CAN experenience, but from the description,
I'd think your proposal above is much better.
>
> But I think this solution cannot easily be ported to Socket-CAN.
>
> Some general notes:
>
> - Bus-errors provide important information on the cause of the error and
> the user/app should have a chance to get it.
>
> - the bus-error rate depends on the bit-rate. It's quite moderate at
> 125KB/s but high at 1MB/s.
>
> - NAPI helps to avoid system hangups and to keep the system responsive.
>
> - Porting the SJA1000 to NAPI would be a solution. I think there is no
> other CAN controller using top-half for bus-error handling.
>
> What do you think?
Maybe clarify that if bus-error generation is disabled, bus state
changes (error-active, error-passive & bus-off) are still enabled.
At least, that the way I like to address the problem.
IMHO, it would avoid a lot of confusion to make this clear.
>
> Wolfgang.
Kurt
> _______________________________________________
> Socketcan-users mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/socketcan-users
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
