Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Wolfgang Grandegger wrote: >>> Back to our preferred solution 1. Attached is a patch for review >>> including some other fixes and suggestions accumulated over time: >>> >>> * ksrc/drivers/can/*: To avoid unnecessary bus error interrupt >>> flooding, the option CONFIG_XENO_DRIVERS_CAN_BUS_ERR now allows to >>> enable bus error interrupts "on demand" only if an application is >>> interested in such errors. It is automatically selected for CAN >>> controllers supporting bus error interrupts like the SJA1000. >> >> Jumping into this more or less blindly: Could you explain to me (as well >> as the poor CAN users...) what the downsides of enabling >> CONFIG_XENO_DRIVERS_CAN_BUS_ERR are? If there isn't anything >> significant, I would strongly vote for keeping the switch forest as >> small as possible. > > The user has not to care and cannot even enable this option. It is auto > selected for SJA1000. The purpose of this config option is to suppress > correlated code for builds without SJA1000. About the functionality: as
Hmm, probably the attached help text confused me (who should see it BTW?). > you know, on the SJA1000 the bus error interrupt can result in high > error interrupt rates and even hang the system on slow processors. Just > unplugging the CAN cable can cause such interrupt flooding. This problem > popped up again recently and Sebastian proposed: > >> Last summer we had a discussion about the BEI issue on the >> socketcan-ML. Two additional handling policies popped up: >> 1. The interface could restart itself after an amount of BEIs, thus >> taking responsibility from the user application. >> 2. The BEI could be completely disabled if no one is interested in >> this ype of error frame. > > As 2. is also my preferred solution, I have implemented it. The only > downside is that you do not see the error counter increasing when > /proc/rtcan/devices is inspected. We also discussed 1., but > RT-Socket-CAN does not restart the CAN controller by purpose and just > stoppping it requires user intervention. And if there is someone listening, how is the flooding issue on cable unplug etc. solved by option 2? What about something like option 3: After the first error occurred that may mark the beginning of a flood, disable that error interrupt until the next stop/start cycle or the user has read the event? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
