Roland Tollenaar wrote: > > The system messages you refer to are generated by the CAN stack. They > > will be generated also without syslogd because they use rtdm_printk() in > > kernel space. > > Here I have a problem. Why then is the business of syslogd related to > the overflowing of the buffer.
CAN socket buffer overflow --> kernel prints warnings --> syslogd logs these warnings This is not exclusively RT-Socket-CAN related. Normally, syslogd logs all kernel messages. > Its a fact that if my buffer over flows > (even if it overflows with normal messages being sent in from another > node) that syslogd becomes very busy (when viewed in top) and the > hardness of the rt app starts faltering. > > Btw I am not explicitly aware of ANY CAN error degrading the RT > behaviour only of the relation between buffer overflow and reduction in > RT performance. As I stated in another mail you can silence the overflow message by configuring it out. But ask yourself if this is really what you want. Losing messages due to an overflowing buffer is nothing that should appear regularly but rather as exception. The kernel message is meant to inform you of this exceptional situation. If you lose messages under RT conditions you very likely have more severe problems than a kernel printing out too much information. > Forget the errors for a moment because I have the same problem with too > many messages coming in on a perfectly healthy bus from a perfectly > healthy node. Right. In fact, for the RAW protocol layer this is the very same situation as with the error frames. In my opinion, a clean design approach is not to silence the warnings because the discarding of CAN frames takes place regardless of this. I think you have to options: 1. If messages are lost sporadically try to enlarge the socker buffer size. 2. If messages are lost permanently your real-time task is overloaded. Try to lower the baud rate, set an appropriate filter or, more likely, rethink your whole system design. If CAN frames are piling up in the socket buffer and your application isn't quick enough to read them out although it does nothing else than receiving them, then there is something going wrong. -- Sebastian _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
