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. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
