Hi Wolfgang, On 21/06/18 11:28, Wolfgang Grandegger wrote: [...snip...] >>>> It's fairly rare to happen even in our unusually harsh environment, >>>> unless we really push it with unrealistically tight loop, so this >>>> definitely comes under crazy edge cases. ;-) >>> Your conditions are special... maybe that's why the problem did not show >>> up yet. >> We're sure of it. It only showed up now as we are soak testing to try >> and reproduce these rare bugs. >>>> I'm just waiting for my turn to try my interrupt idea on the hardware (I >>>> hogged it yesterday) and reading the datasheet. >>>> Even if that works, I'm still thinking it might be an idea to check for >>>> bus off in the send as a fall back with a "this should never happen" >>>> kind of warning. >>> BTW, what hardware (Board/CPU) are you using? >> It's a Beagle Bone Black, TI's AM335x. It's part of a stack of prototype >> boards we designed. > OK. How do you recover from bus-off? What "ip" command do you use to > configure the device? This is in a small Buildroot image and we're using ifup and ifdown: https://ss64.com/bash/ifup.html It uses /etc/network/interfaces to know how to setup the CAN interfaces. I'm on the machine now and trying things. I can reduce the problem with: static irqreturn_t c_can_isr(int irq, void *dev_id) { struct net_device *dev = (struct net_device *)dev_id; struct c_can_priv *priv = netdev_priv(dev); if (!priv->read_reg(priv, C_CAN_INT_REG)) { // It is possible the interrupt register has been cleared if (priv->last_status == priv->read_reg(priv, C_CAN_STS_REG)) return IRQ_NONE; } /* disable all interrupts and schedule the NAPI */ c_can_irq_control(priv, false); napi_schedule(&priv->napi); return IRQ_HANDLED; } If I add a flag variable in "priv" and print out if it is set in "c_can_poll" I can see there are times that this is catching. But it's just failed so this isn't a complete solution. > Wolfgang. Joe -- To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
