Wolfgang Grandegger wrote: > Kurt Van Dijck wrote: >> On Fri, Feb 05, 2010 at 11:44:42AM +0100, Wolfgang Grandegger wrote: >>> Oliver Hartkopp wrote: >>>> christian pellegrin wrote: >>>>> On Fri, Feb 5, 2010 at 10:05 AM, Kurt Van Dijck <[email protected]> >>>>> wrote: >>>>> >>>>>> I never enabled the bus-error interrupts anywhere embedded. >>>>>> To research odd behaviour, the error counters were helpfull, >>>>> I like this idea much. I speak from a point of view of meanness ;-) : >>>>> we have paid the chip manufacturer for the REC and TEC counters that >>>>> are cleverly incremented and decremented (AFAIK it's more likely they >>>>> are incremented that decremented, so there is always a window in which >>>>> the user space application can catch an increase in them even if not >>>>> polling at an excessive rate) by the controller itself so they could >>>>> be easily exported to user space. Perhaps all we need is a function >>>>> for this in can_priv such do_get_err_counters. Even better if these >>>>> counters are exported via sysfs so the function above is guaranteed to >>>>> be called in non-atomic context. >>>>> >>>> Trying to summarize these points, what about this: >>>> >>>> 1. We disable bus-error interrupts by default >>> Fine for me, even if that changes the current behavior. >> Ack >>>> 2. They can be enabled via netlink >>> Yep. >> Ack >>>> 3. Once they are enabled we send the (unified) rx/tx error counters inside >>>> the >>>> currently reserved bytes of the CAN error frame to the userspace. >>> The problem is that some CAN controllers do not allow to read these >>> counters while it's active. But in general we could add the rx/txerr to >>> any error message, if possible. The information in the error message is >>> hardware dependent anyway. >> Ack >>>> Would this meet the requirements in production-use and development-use ?? >> Yes, for me, this would meet the requirements. > > OK, the preliminary patch for SVN below implements this solution and shows > what we are speaking about. As a nice side effect, it also allows to check > if the device supports bus-error reporting. Marc, could you please check > the at91_can modifications?
I had a closer look and they are not OK. There are sources for the various bus-errors, which can be enabled individually. See: http://lxr.linux.no/#linux+v2.6.32/drivers/net/can/at91_can.c#L636 I realized some confusion between the following two errors: #define CAN_ERR_ACK 0x00000020U /* received no ACK on transmission */ #define CAN_ERR_BUSERROR 0x00000080U /* bus error (may flood!) */ Here, I think we speak about bus errors, which increment the TX and RX error counters. The at1_can treats currently the AT91_IRQ_AERR as CAN_ERR_ACK, which is a bus error as well. On the SJA1000 the error is signaled as: can_id |= CAN_ERR_BUSERROR | CAN_ERR_PROT; data[2] |= CAN_ERR_PROT_UNSPEC; data[3] |= CAN_ERR_PROT_LOC_ACK; /* ACK slot */ I cannot remember why we introduced CAN_ERR_ACK. For the AT91, I think we should add CAN_ERR_BUSERROR, and treat it as bus error, at least. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
