AnsweredAssumed Answered

LS1021A Qoriq SDK-v2.0 eTSEC error handling (Busy error) but RSTATn[QHLTm] is not cleared, so controller remains halted

Question asked by Peter Sijpkes on Jun 12, 2018
Latest reply on Jun 20, 2018 by Yiping Wang

In a test with many illegally fragmented ICMP echo request frames we get into a situation where at some point nothing is processed anymore, the controller (TSEC) is halted as indicated by RSTATn bit QHLTm.

 

During this test the IEVENT triggers on event BSY. This is handled in the gianfar error handler (gfar_error). Bit QHLTm of RSTATn is set. The documentation mentions for the Error-handling procedure, reception errors: "The halted queue resumes reception once the RSTATn[QHLTm] bit is cleared". However this does not happen.

 

When done by hand this actually resolves the issue, the question is how this should work ?  Shouldn't the error handler take care of the RSTAT clear ?

 

To point out some detail, after switching on debug we get the following print just before we get stuck:
Jan  1 17:54:03 ls1021atwr user.debug kernel: fsl-gianfar soc:ethernet@2d10000 eth0: error interrupt (ievent=0x20000000 imask=0xf1310083)
Jan  1 17:54:03 ls1021atwr user.debug kernel: fsl-gianfar soc:ethernet@2d10000 eth0: busy error (rstat: 800080)

Any help is appreciated

Outcomes