Hello All,
Sometimes the FEC driver will stall with a descriptor in the DMA ring that's ready for transmit but FEC_X_DES_ACTIVE bit is not enabled. This buffer will remain jammed in the ring until another transmit request is queued.
Has anyone else seen this issue? Is there a known solution?
We have worked around the problem by keeping a count of tx ready descriptor, then we check that count at the end of fec_enet_rx(). If we have at least one tx descriptor ready, but the DMA TX controller is not active, we give it a bump.
We would like to avoid this situation rather than work around it.
Thanks,
Seth
Comment found in actual u-boot driver:
================================================================
When only one BD is in
* use it must be marked with the WRAP bit to use it for every transmitt.
* This bit in combination with the READY bit results into double transmit
* of each data buffer. It seems the state machine checks READY earlier then
* resetting it after the first transfer.
* Using two BDs solves this issue.
========================================================
We observed similar problems on processing the last descriptor in a ringbuffer.....
What´s even more scary - is that is obvious race condition depends somehow on chip revisions.
Identical code failed on our board - but not on the evk. So be careful with the last descriptor ;-))
I don't have any details about the problem you mention. 2.6.35 kernel does not receive any more updates, so it is a good idea to try 3.0 to check if the problem still exists or not.
If you see the problem, then the drivers/net folks would be interested in fixing it.
We don't have a BSP for the 3.0 kernel. It will take some time to get that working. I will let you know when I gather that data.
Is there a reason you think this is fixed in kernels beyond 2.6.35.14?
Thanks,
Seth
Could you please try a 3.0 kernel and let us know if you face the same issue?
If you do, please list the steps on how to reproduce this problem.
Regards,
Fabio Estevam