Hi Anssi Hannula, <Snip> > >> recessive bits have been seen, so that would not work. > > Could you please provide the steps to reproduce this issue?? > > > > Sure. Below are instructions for reproducing this by just using CAN FD > cores to disrupt the bus. > I believe the instructions will likely work with other Xilinx CAN cores, > too (and the secondary CAN interface(s) probably don't need to be Xilinx). > > > Scenario A - Failure to bring interface up with invalid bus state: > > 1. Connect 2 CAN FD cores to a properly terminated bus with no other > participants. > > 2. Start one interface at 1000k and start sending frames (well, at least > try to send). > > # ip link set dev can2 up type can bitrate 1000000 restart-ms 2000 > # cangen can2 -I 42A -p 100 > > 3. Try to enable another interface at 125k - the other interface we > started earlier will prevent this interface from seeing the 11 recessive > bits: > > # ip link set dev can1 up type can bitrate 125000 restart-ms 2000 > RTNETLINK answers: Connection timed out > > [ 49.276765] xilinx_can a0002000.canfd can1: timed out for correct mode > [ 49.283295] xilinx_can a0002000.canfd can1: xcan_chip_start failed! > [ 49.289629] A link change request failed with some changes committed > already. Interface can1 may have been left with an inconsistent > configuration, please check. > > > Scenario B - A temporary bus fault causes the interface to never come > back up again even with restart-ms: > > We will trigger a bus-off and have the bus be in the scenario A state > when the restart is being done. > > 1. Connect 3 CAN FD cores to a properly terminated bus with no other > participants. > > 2. Start interfaces: > > # ip link set dev can1 up type can bitrate 125000 restart-ms 16000 > # ip link set dev can2 up type can bitrate 125000 restart-ms 16000 > # ip link set dev can3 up type can bitrate 125000 restart-ms 16000 > > 3. Start observing can1: > > # candump -D -cc can1 > > 4. Verify that bus is OK and a frame can be sent. It should be seen in > the above candump output. > > # cansend can1 "123#11223344" > > 5. Make can1 enter bus-off. Here we do it by changing the bitrate of the > 2 other interfaces and adding traffic > > # ip link set dev can2 down > # ip link set dev can2 up type can bitrate 1000000 restart-ms 2000 > # ip link set dev can3 down > # ip link set dev can3 up type can bitrate 1000000 restart-ms 2000 > # cangen can2 -I 42A -p 100 -g 1 > (keep cangen running) > > and then trying to send a frame from can1: > > # cansend can1 "123#11223345" > > The frame will (expectedly) not show up in candump and > > # ip -d link show can1 > > should show the state be in BUS-OFF soon after the command. > > [ 64.777854] xilinx_can a0002000.canfd can1: bus-off > > 6. Within 16 sec (restart-ms) of the above cansend command, stop can3 to > get the bus into a state that prevents can1 restart (i.e. it will not > see 11 recessive bits): > > # ip link set dev can3 down > > When the restart-ms triggers, you will get: > > [ 81.864783] xilinx_can a0002000.canfd can1: timed out for correct mode > [ 81.871309] xilinx_can a0002000.canfd can1: xcan_chip_start failed! > [ 81.877574] xilinx_can a0002000.canfd can1: Error -110 during restart > > 7. Bring the bus back to a valid state: > > # ip link set dev can2 down > # ip link set dev can2 up type can bitrate 125000 restart-ms 2000 > # ip link set dev can3 down > # ip link set dev can3 up type can bitrate 125000 restart-ms 2000 > > But can1 will remain in BUS-OFF forever. Frames cannot be sent from can1 > despite the bus actually being OK now and restart-ms being active. > In reality the can1 HW is fine and in error-active at this point, just > the Linux interface is in BUS-OFF as xcan_chip_start() failed in step 6. Thanks for the detailed steps... Please give me some time will reproduce this issue and will get back to you with my test observations ASAP. Regards, Kedar. > > > > > >> Checked on CAN FD 1.0 on ZynqMP. > >> > >> > >>> Regards, > >>> Kedar. > >>> > >>>>> netdev_dbg(ndev, "status:#x%08x\n", > >>>>> priv->read_reg(priv, XCAN_SR_OFFSET)); > >>>>> > >>>>> > >>>> Xilinx folks: Please take a look at this RFC. > >>>> > >>>> Thanks, > >>>> Michal > >> > >> -- > >> Anssi Hannula / Bitwise Oy > >> +358 503803997 > > > -- > Anssi Hannula / Bitwise Oy > +358 503803997
