On Thu, Feb 04, 2010 at 11:35:17AM +0100, Marc Kleine-Budde wrote:
>
> Wolfgang Grandegger wrote:
> >>>>>>> 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
>
> I'm not sure about the spinlock, we might also be in the NAPI context
> (IIRC softirq that is). But that will clarify later when we have an
> example implementation....
>
> >>>> 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.
>
> ...and on the selected bitrate.
>
> I think a "pure" ratelimit isn't a good choice. From my point of view
> (with no CAN background) we should limit only if the errors are
> consecutive, a successfully transmitted or received CAN frame should
> reset our limiter.
Or a bus-off indication.
Resetting the rate-limit at successfull tx or rx requires disabling
_only_ the bus-error interrupt and not the TX & RX interrupt,
and is therefore chip specific?
>
> Maybe a real world CAN expert can say something to this.
>
> cheers, Marc
Kurt
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
