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? In RT-Socket-CAN, bus-errors are only delivered on demand. See: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/Kconfig#052 But I think this solution cannot easily be ported to Socket-CAN. Some general notes: - Bus-errors provide important information on the cause of the error and the user/app should have a chance to get it. - the bus-error rate depends on the bit-rate. It's quite moderate at 125KB/s but high at 1MB/s. - NAPI helps to avoid system hangups and to keep the system responsive. - Porting the SJA1000 to NAPI would be a solution. I think there is no other CAN controller using top-half for bus-error handling. What do you think? Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
