Hi Anssi Hannula, > -----Original Message----- > From: Appana Durga Kedareswara Rao > Sent: Tuesday, March 19, 2019 11:58 AM > To: Anssi Hannula <anssi.hannula@xxxxxxxxxx>; Michal Simek > <michals@xxxxxxxxxx>; linux-can@xxxxxxxxxxxxxxx; Marc Kleine-Budde > <mkl@xxxxxxxxxxxxxx> > Cc: Wolfgang Grandegger <wg@xxxxxxxxxxxxxx>; Shubhrajyoti Datta > <shubhraj@xxxxxxxxxx>; Naga Sureshkumar Relli <nagasure@xxxxxxxxxx> > Subject: RE: [RFC PATCH] can: xilinx_can: fix chip_start failure with invalid bus > > 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. I have tried both the scenarios and able to reproduce the issue, CAN is in configuration mode when the bus-off happened(I mean when timeout happens), As per spec core exits Configuration mode after the CEN bit is set and consecutive 11 nominal recessive bits are seen on the CAN bus, this is criteria for CAN node to exit configuration mode. I have cross-checked with h/w owner for any specific timeout value for this scenario as per him There is no specific timeout we can wait for this scenario, By considering the above limitations this patch is fine as we are doing a reset in the chip_start which will error out in case of h/w design has some invalid configuration for CAN IP. Feel free to add, Tested-by: Appana Durga Kedareswara Rao <appana.durga.rao@xxxxxxxxxx> Regards, Kedar. > > 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
