Kurt Van Dijck wrote:
> 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?
Have you ever thought about ratelimit?
In
http://lxr.linux.no/#linux+v2.6.32/lib/ratelimit.c
there is an implementation that's usually used e.g. as net_ratelimit() to slow
down printks at several locations inside the kernel.
As we are already in interrupt context there's no spin_lock_irqsave() needed,
but we might implement an extra can_ratelimit() using a private
struct ratelimit_state buserr_ratelimit;
we could add to the in the can_priv structure.
Regards,
Oliver
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
