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
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.
Wolfgang.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
