Marc Kleine-Budde wrote: > Wolfgang Grandegger wrote: >> Oliver Hartkopp wrote: >>> 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. >> Hm, this will only help partially. We need to decrease the interrupt >> rate not just the delivery rate. Or have I missed something? Also, >> bus-errors in sequence might provide useful information. > > With a ratelimit we can detect if an error interrupt fires "too often". > If the "ratelimit" triggers the interrupt should be masked. It must be > re-enabled after a certain time though.
Yes, disable the bus-error interrupt after a certain amount and re-enable it after some time, would be my favorite as well. But choosing the right parameters is not easy and depends on the CPU power. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
